Submit burn tx

POST /api/v1/mystery/redemption/submit cards:redeem

Records the burn tx the end user broadcast, moving the redemption PREPARED → BURN_SUBMITTED (202 — fulfillment is asynchronous). A fast-path courtesy: the worker also converges from on-chain state, so an un-submitted burn still advances the redemption. Re-submitting the same hash is idempotent.

Try it POST /api/v1/mystery/redemption/submit write

These inputs are shared across all docs pages — an id entered here carries over.

request body
object · 2 keys
{
  "redemption_id": 0,
  "tx_hash": "0x0000000000000000000000000000000000000000000000000000000000000000"
}
response

Not run yet — press Run to make a live call against https://staging-service.rip.fun (through this demo's server-side proxy; the API key never reaches the browser).

curl (tracks the inputs above)
curl -X POST 'https://staging-service.rip.fun/api/v1/mystery/redemption/submit' \
  -H 'X-API-Key: rip_v1_…' \
  -H 'Content-Type: application/json' \
  -d '{"redemption_id":0,"tx_hash":"0x0000000000000000000000000000000000000000000000000000000000000000"}'

Request fields

FieldTypeRequiredDescription
redemption_idnumberyesFrom the prepare response
tx_hashstringyes0x-prefixed 32-byte hash of the burn tx

Response fields (data)

FieldDescription
redemption_id / status / burn_tx_hashBURN_SUBMITTED + the recorded hash

Errors

StatusCodeWhen
400invalid_tx_hashnot a 0x-prefixed 32-byte hash
409kyc_requiredredemption is still AWAITING_KYC
409invalid_statusredemption is in any other non-PREPARED state
404not_foundunknown redemption_id

See Errors for the response envelope and the full code list.