Access & receipts

Re-verify receipts and unlock paid resources. Sellers should store used receipt_ids for one-time unlock even when protocols also return Payment-Receipt headers.

Same flow in MCP: rill_verify_receipt

Auth

POST /access/verify is public (pass the receipt). Listing receipts follows owner/VW auth on GET /receipts. Seed unlock uses X-Rill-Receipt on GET /demo/echo after a ledger pay.

Featured endpoints

Verify a receipt

POST /access/verify

Re-check a receipt after pay. Optional resource_id scopes the verify call. Open-world Accept gates may also accept Payment-Receipt / PAYMENT-RESPONSE headers from MPP/x402 clients, still store used receipt_ids server-side for one-time unlock.

Parameter	Type	Required	Description
`receipt_id`	string	yes	Receipt id returned from a successful pay
`resource_id`	string	no	Optional resource scope for the verify call

Request body

body

{
  "receipt_id": "…",
  "resource_id": "SEED23"
}

What to save

Treat a successful verify as unlock proof for that receipt. Persist used receipt_ids so the same receipt cannot unlock twice.

Seed unlock over HTTP: GET /demo/echo with X-Rill-Receipt after paying SEED23 on the ledger.
MCP twin: rill_verify_receipt.

All endpoints

POST/access/verifyRe-verify receipt (optional resource_id)
GET/receiptsList receipts
GET/demo/echoSeed unlock with X-Rill-Receipt
GET/r/:resourceIdHosted gate 402 → pay → unlock

Usage notes

Verification is re-checkable; sellers enforce one-time unlock by storing used receipt_ids.
Hosted pay page (web): /r/:resourceId · balise script: /rill-balise.js.