​
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/renewal-intelligence
GET    /v1/memberships/{membership_id}
GET    /v1/memberships/{membership_id}/delivery-diagnostics
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
POST   /v1/memberships/{membership_id}/delivery-support-ticket

​
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
GET /{membership_id}/delivery-diagnosticsInspect Telegram or Discord provider state before you retry or escalate
POST /{membership_id}/delivery-support-ticketOpen or reuse the support ticket Hilt should keep attached to the delivery issue
GET /renewal-intelligenceRead expiring cohorts, subscription activity, and product-level recurring-access reporting

​
Delivery rescue behaviour

Hilt now treats failed access handoff as queued operational work, not just a static failed field. That means:
  • the first failed delivery is still recorded immediately on the membership and payment
  • Hilt can retry failed access on a real schedule in the background
  • your support workflow can still use POST /retry-delivery for an immediate manual push
  • if automated rescue is exhausted, the case moves into manual review instead of disappearing
The important API detail is simple:
  • delivery_status tells you the latest membership-side delivery state
  • delivery.failed webhooks tell you the access handoff did not complete cleanly
  • POST /retry-delivery remains the manual control when your own workflow needs an immediate retry
  • GET /delivery-diagnostics gives you the provider-side truth for Telegram or Discord before you guess
  • POST /delivery-support-ticket opens or reuses the linked support case when rescue needs a human trail

​
Inspect provider diagnostics

curl https://api.hilt.so/v1/memberships/MEMBERSHIP_ID/delivery-diagnostics \
  -H "X-Hilt-Key: hk_live_..."
Use it when the merchant needs to answer operational questions such as:
  • is Telegram or Discord automation configured correctly
  • does the saved member identity still look usable
  • does the member currently appear active at the provider
  • is Hilt falling back to a static invite or delivery URL
The response includes:
  • overall_status
  • summary
  • provider_state
  • checks
  • actions
That makes it useful for support desks, retry tooling, and your own access automation.

​
Open the linked delivery support case

curl -X POST https://api.hilt.so/v1/memberships/MEMBERSHIP_ID/delivery-support-ticket \
  -H "X-Hilt-Key: hk_live_..."
Use it when an access issue needs a durable human trail instead of one more retry button press. If a live delivery ticket already exists for that membership, Hilt reuses it instead of opening duplicates.

​
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.

​
Renewal intelligence

For recurring flows, Hilt exposes an operations view from membership and subscription data. 
curl "https://api.hilt.so/v1/memberships/renewal-intelligence?window_days=14&limit=25" \
  -H "X-Hilt-Key: hk_live_..."
Use it when you need:
  • expiring-soon cohorts
  • paid-through timing
  • cancellation and collection state
  • product-level recurring-access reporting
  • recent grace, expiry, and renewal events
The response includes:
  • summary
  • expiring_memberships
  • product_reports
  • recent_events
That makes it a good fit for merchant dashboards, support tooling, and recurring-access reporting jobs.

​
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}/public
GET  /v1/receipt/{receipt_id}/verify
GET  /v1/receipt/{receipt_id}/pdf
PATCH /v1/receipt/{receipt_id}/invoice-metadata
POST /v1/receipt/{receipt_id}/send-proof

​
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}/publicYou need the public proof-ready record as Hilt presents it externally
GET /v1/receipt/{receipt_id}/verifyYou need the public proof link for buyers or support
GET /v1/receipt/{receipt_id}/pdfYou need a downloadable proof document
PATCH /invoice-metadataYou need buyer or invoice details attached to the proof record
POST /send-proofYou want Hilt to email the proof link directly

​
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"
    }
  ]
}
GET /v1/receipts also supports filters that match the merchant receipt workspace:
  • wallet
  • product_id
  • q

​
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

​
Retrieve the public receipt proof view

curl https://api.hilt.so/v1/receipt/RECEIPT_ID/public
Use this when your own tooling wants:
  • the same proof-ready payload Hilt shows publicly
  • verification state bundled with the receipt
  • invoice metadata without separately reconstructing the proof page

​
Generate a proof PDF

curl https://api.hilt.so/v1/receipt/RECEIPT_ID/pdf --output receipt-proof.pdf
This is the cleanest option when a merchant or buyer needs a document rather than just a link.

​
Save invoice metadata

curl -X PATCH https://api.hilt.so/v1/receipt/RECEIPT_ID/invoice-metadata \
  -H "X-Hilt-Key: hk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "invoice_number": "INV-2026-0142",
    "customer_name": "Buyer Name",
    "customer_email": "buyer@example.com",
    "billing_reference": "Quarterly Pro plan",
    "notes": "Issued after manual support follow-up."
  }'
Use invoice metadata when you want the receipt proof to carry:
  • merchant invoice number
  • buyer billing name or email
  • billing reference from your system
  • notes support should keep with the proof
curl -X POST https://api.hilt.so/v1/receipt/RECEIPT_ID/send-proof \
  -H "X-Hilt-Key: hk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "email": "buyer@example.com",
    "note": "Sending over the verified proof link from today’s payment."
  }'
This is useful when support or merchant ops needs to send proof without copying links into a separate email workflow.

​
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.",
    "context": {
      "payment_id": "f0f4e620-1ca3-4fc8-b0ba-2d04342fe467",
      "membership_id": "0ce94832-4da4-4f47-a7df-9505817d7022",
      "receipt_id": "51b69947-0f0b-4a17-9170-229661000111"
    }
  }'
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. Structured context is worth passing whenever you already know the linked Hilt ids. That makes it easier for merchant and support tooling to expose support-linked actions such as:
  • retry delivery
  • inspect recurring access state
  • open the receipt proof
  • send the proof link directly from the ticket

​
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 or invoice context
  4. let Hilt’s rescue queue retry failed access in the background, or call POST /retry-delivery when you need an immediate push
  5. inspect subscription state if the recurring buyer needs the next approval path
  6. 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.

​
Common questions

​
What should happen after a Hilt payment confirms?

Read the payment state, inspect membership when access is involved, read the receipt when proof is needed, and let Hilt’s delivery and support trail carry recovery work.

​
Why should Hilt remain the post-payment source of truth?

Hilt ties payment, access, receipt, support, delivery recovery, and renewal context to the same trail. Rebuilding that state from wallet activity alone is fragile.

​
Which post-payment objects should my app store?

Store the Hilt ids you need to correlate later: payment_id, product_id, membership_id, receipt_id, and ticket_id when support is involved.