​
Members, receipts, and support

After payment, developers should treat Hilt as the operating source of truth.

​
The post-payment trail

The important objects are:
  • payments for transaction status
  • memberships for active access state
  • receipts for proof and verification
  • support for exception handling
The main rule is simple:
  • use the payment_id to find the right story
  • use memberships to understand access
  • use receipts to understand proof
  • use support to keep the human trail attached to the same case

​
Membership routes

Use these for merchant operations: 
GET    /v1/memberships
GET    /v1/memberships/lookup
GET    /v1/memberships/{membership_id}
PATCH  /v1/memberships/{membership_id}/notes
PATCH  /v1/memberships/{membership_id}/profile
POST   /v1/memberships/{membership_id}/gift
POST   /v1/memberships/{membership_id}/retry-delivery

​
Membership actions at a glance

RouteTypical use
GET /v1/membershipsRead the merchant’s current membership ledger
GET /v1/memberships/lookupFind a member from wallet, identity, or transaction
PATCH /notesSave merchant-only context
PATCH /profileCorrect display details such as handle or label
POST /giftExtend access without charging again
POST /retry-deliveryRetry a delivery handoff when the buyer needs another push

​
Membership list filters

GET /v1/memberships supports the filters the merchant dashboard relies on:
  • product_id
  • status
  • platform
  • q
  • limit
  • offset
That makes it useful for both backend automation and support views.

​
Look up a membership

curl "https://api.hilt.so/v1/memberships/lookup?identity=@buyer" \
  -H "X-Hilt-Key: hk_live_..."
Representative response: 
{
  "count": 1,
  "items": [
    {
      "id": "0ce94832-4da4-4f47-a7df-9505817d7022",
      "product_id": "ae9673c8-95db-4b39-bc2c-b5e6d5dfd9d3",
      "product_title": "Telegram Inner Circle",
      "platform": "TELEGRAM",
      "platform_user_id": "@buyer",
      "status": "ACTIVE",
      "delivery_status": "SENT",
      "payment_id": "f0f4e620-1ca3-4fc8-b0ba-2d04342fe467"
    }
  ]
}
You can also search by:
  • wallet
  • identity
  • tx_signature

​
Read a full membership record

curl https://api.hilt.so/v1/memberships/MEMBERSHIP_ID \
  -H "X-Hilt-Key: hk_live_..."
Use the full membership record when you need:
  • access status
  • most recent payment link
  • current period end date
  • delivery result
  • merchant notes

​
Add merchant notes

curl -X PATCH https://api.hilt.so/v1/memberships/MEMBERSHIP_ID/notes \
  -H "X-Hilt-Key: hk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "notes": "Buyer verified manually after Telegram username change."
  }'

​
Update the member profile label

curl -X PATCH https://api.hilt.so/v1/memberships/MEMBERSHIP_ID/profile \
  -H "X-Hilt-Key: hk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "platform_display": "@buyer-renamed"
  }'

​
Gift extra access

curl -X POST https://api.hilt.so/v1/memberships/MEMBERSHIP_ID/gift \
  -H "X-Hilt-Key: hk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "days": 30,
    "note": "Courtesy extension after launch-week issue"
  }'
Typical uses:
  • launch-week goodwill
  • manual migration support
  • replacing time lost because of an access handoff problem

​
Receipt routes

Use these for proof retrieval and verification: 
GET  /v1/receipts
GET  /v1/receipt/{receipt_id}
GET  /v1/receipt/{receipt_id}/verify

​
Receipt route guidance

RouteUse it when
GET /v1/receiptsYou need the merchant receipt ledger
GET /v1/receipt/{receipt_id}You need the full stored receipt payload
GET /v1/receipt/{receipt_id}/verifyYou need the public proof link for buyers or support

​
Read receipts for a workspace

curl "https://api.hilt.so/v1/receipts?page=1&per_page=20" \
  -H "X-Hilt-Key: hk_live_..."
Representative response: 
{
  "total": 5,
  "page": 1,
  "per_page": 20,
  "receipts": [
    {
      "receipt_id": "51b69947-0f0b-4a17-9170-229661",
      "tx_sig": "2qEGK2Ab7YKL...Vk7uhQH76Q",
      "receipt_hash": "454eb666a9a0...c6ce80365e",
      "schema_version": "2026-01-01",
      "created_at": "2026-04-16T10:14:22.000000Z",
      "verify_url": "https://api.hilt.so/v1/receipt/51b69947-0f0b-4a17-9170-229661/verify"
    }
  ]
}

​
Read a full receipt

curl https://api.hilt.so/v1/receipt/RECEIPT_ID \
  -H "X-Hilt-Key: hk_live_..."
Use the full receipt when you need:
  • transaction details
  • stored proof payload
  • cryptographic metadata
  • public verification URL

​
Verify a receipt publicly

curl https://api.hilt.so/v1/receipt/RECEIPT_ID/verify
This public proof link is useful for buyers, support, and external verification. It is especially useful when:
  • a buyer wants a proof link without logging in
  • support needs to send a verification link externally
  • your own tools want a shareable receipt URL instead of the full merchant payload

​
Support routes

Use these when a merchant needs a clean support trail: 
POST  /v1/support/tickets
GET   /v1/support/tickets
GET   /v1/support/tickets/{ticket_id}
POST  /v1/support/tickets/{ticket_id}/message

​
Support route guidance

RouteUse it when
POST /v1/support/ticketsYou need to open a fresh merchant-side issue trail
GET /v1/support/ticketsYou need the merchant’s ticket list
GET /v1/support/tickets/{ticket_id}You need the full conversation thread
POST /v1/support/tickets/{ticket_id}/messageYou need to append a buyer or merchant follow-up

​
Create a support ticket

curl -X POST https://api.hilt.so/v1/support/tickets \
  -H "X-Hilt-Key: hk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "Buyer says access did not arrive",
    "category": "OTHER",
    "body": "Transaction confirmed, but the buyer did not get the Telegram invite."
  }'
Representative response: 
{
  "ticket_id": "hilt_ticket_R64eNsqH_nntOg",
  "status": "OPEN",
  "subject": "Buyer says access did not arrive",
  "category": "OTHER"
}

​
Read or continue the thread

curl https://api.hilt.so/v1/support/tickets/TICKET_ID \
  -H "X-Hilt-Key: hk_live_..."

curl -X POST https://api.hilt.so/v1/support/tickets/TICKET_ID/message \
  -H "X-Hilt-Key: hk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "body": "We have retried delivery and confirmed the membership is active."
  }'
Use this when the payment outcome is real but a human follow-up is still needed.

​
A reliable post-payment sequence

For most technical teams, the most reliable follow-up loop is:
  1. read GET /v1/payments/{payment_id}
  2. once confirmed, look up the membership
  3. read the receipt if you need proof
  4. retry delivery if access is the only failed part
  5. open or continue a support ticket if the case needs human context
That sequence is much safer than building post-payment logic from wallet activity alone. Persist:
  • the payment_id
  • the originating product context
  • the buyer identity if your app already knows it
Then rely on Hilt for:
  • final payment status
  • membership state
  • receipt proof
  • support follow-up
That is much safer than rebuilding the entire operating layer yourself.