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

Route	Typical use
`GET /v1/memberships`	Read the merchant’s current membership ledger
`GET /v1/memberships/lookup`	Find a member from wallet, identity, or transaction
`PATCH /notes`	Save merchant-only context
`PATCH /profile`	Correct display details such as handle or label
`POST /gift`	Extend access without charging again
`POST /retry-delivery`	Retry a delivery handoff when the buyer needs another push
`GET /{membership_id}/delivery-diagnostics`	Inspect Telegram or Discord provider state before you retry or escalate
`POST /{membership_id}/delivery-support-ticket`	Open or reuse the support ticket Hilt should keep attached to the delivery issue
`GET /renewal-intelligence`	Read 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

Route	Use it when
`GET /v1/receipts`	You need the merchant receipt ledger
`GET /v1/receipt/{receipt_id}`	You need the full stored receipt payload
`GET /v1/receipt/{receipt_id}/public`	You need the public proof-ready record as Hilt presents it externally
`GET /v1/receipt/{receipt_id}/verify`	You need the public proof link for buyers or support
`GET /v1/receipt/{receipt_id}/pdf`	You need a downloadable proof document
`PATCH /invoice-metadata`	You need buyer or invoice details attached to the proof record
`POST /send-proof`	You 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

Send a proof link

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

Route	Use it when
`POST /v1/support/tickets`	You need to open a fresh merchant-side issue trail
`GET /v1/support/tickets`	You need the merchant’s ticket list
`GET /v1/support/tickets/{ticket_id}`	You need the full conversation thread
`POST /v1/support/tickets/{ticket_id}/message`	You 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:

read GET /v1/payments/{payment_id}
once confirmed, look up the membership
read the receipt if you need proof or invoice context
let Hilt’s rescue queue retry failed access in the background, or call POST /retry-delivery when you need an immediate push
inspect subscription state if the recurring buyer needs the next approval path
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.

Recommended automation loop

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.

Start here

After payment

Examples and reference

Members, receipts, and support

Members, receipts, and support

The post-payment trail

Membership routes

Membership actions at a glance

Delivery rescue behaviour

Inspect provider diagnostics

Open the linked delivery support case

Membership list filters

Renewal intelligence

Look up a membership

Read a full membership record

Add merchant notes

Update the member profile label

Gift extra access

Receipt routes

Receipt route guidance

Read receipts for a workspace

Read a full receipt

Verify a receipt publicly

Retrieve the public receipt proof view

Generate a proof PDF

Save invoice metadata

Send a proof link

Support routes

Support route guidance

Create a support ticket

Read or continue the thread

A reliable post-payment sequence

Recommended automation loop

Common questions

What should happen after a Hilt payment confirms?

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

Which post-payment objects should my app store?

​Members, receipts, and support

​The post-payment trail

​Membership routes

​Membership actions at a glance

​Delivery rescue behaviour

​Inspect provider diagnostics

​Open the linked delivery support case

​Membership list filters

​Renewal intelligence

​Look up a membership

​Read a full membership record

​Add merchant notes

​Update the member profile label

​Gift extra access

​Receipt routes

​Receipt route guidance

​Read receipts for a workspace

​Read a full receipt

​Verify a receipt publicly

​Retrieve the public receipt proof view

​Generate a proof PDF

​Save invoice metadata

​Send a proof link

​Support routes

​Support route guidance

​Create a support ticket

​Read or continue the thread

​A reliable post-payment sequence

​Recommended automation loop

​Common questions

​What should happen after a Hilt payment confirms?

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

​Which post-payment objects should my app store?

Members, receipts, and support

The post-payment trail

Membership routes

Membership actions at a glance

Delivery rescue behaviour

Inspect provider diagnostics

Open the linked delivery support case

Membership list filters

Renewal intelligence

Look up a membership

Read a full membership record

Add merchant notes

Update the member profile label

Gift extra access

Receipt routes

Receipt route guidance

Read receipts for a workspace

Read a full receipt

Verify a receipt publicly

Retrieve the public receipt proof view

Generate a proof PDF

Save invoice metadata

Send a proof link

Support routes

Support route guidance

Create a support ticket

Read or continue the thread

A reliable post-payment sequence

Recommended automation loop

Common questions

What should happen after a Hilt payment confirms?

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

Which post-payment objects should my app store?