Redemption history
Newest first, capped at 500. Closest thing to an orders table for zero-sat claims.
/api/coupons/redemptionsNewest first, capped at 500. Closest thing to an orders table for zero-sat claims.
Nostr <base64 of kind 27235 event>. Tags: u, method, optional
payload (sha256 hex of body), and a random nonce to avoid replay.
In: header
Response Body
application/json
curl -X GET "https://example.com/api/coupons/redemptions"{ "redemptions": [ { "nonce": "string", "claimedAt": 0, "couponId": "string", "name": "string", "benefit": { "type": "percent", "percent": 0, "productDs": [ "string" ], "cap": { "amount": 1, "currency": "ARS" } }, "order": { "id": "string", "pubkey": "string", "created_at": 0, "kind": 0, "tags": [ [ "string" ] ], "content": "string", "sig": "string" }, "orderId": "string", "amountMsat": 0 } ]}Revoke a minter DELETE
Does not touch already-minted coupons.
Swap a nonce for its replacement POST
This is the `refreshUrl` from the announcement. Burns `nonce` and mints a replacement in the same transaction, carrying the **same** benefit snapshot and the **same** `expiresAt`. Refresh is how a coupon changes hands: the nonce is the credential, so re-minting it is the transfer. `Idempotency-Key` is required. The key and the signed response are stored on the burned row, and a retry with the same key replays that response verbatim — never re-signed, because a different event `id` breaks a receiver that already stored the first one. Refuses anything not `minted` and unexpired. The burn is a conditional update, so two callers racing the same nonce produce exactly one replacement and one `409`.