fulfillments

Submit a reward fulfillment (service broadcast)

Service-key only (today enforcer-airdrop). Records that the service broadcast the payout for reward fulfillment id from its treasury wallet: pending → submitted with tx_hash, then a best-effort settlement attempt from that transaction's receipt (the enforcer-reconcile sweep retries it regardless).

Reward rows only. The row must belong to X-Tenant-ID (404 otherwise — existence is not revealed across tenants) and its reference must carry the RWD: tag (403 not_a_reward_fulfillment); a service key cannot stamp a P2P, bill-pay or POS row.

Idempotent. A row that already carries this same hash — submitted, or confirmed because the Routed webhook got there first — answers 200 with the current row. A confirmed row with no hash is stamped with this one. A different hash is 409 tx_hash_conflict; an expired/declined/cancelled/failed row is 409 not_pending.

Settlement: a route-rail payout confirms from its Routed(memo) event as today. A send-rail payout (plain ERC-20 transfer) confirms from the Transfer log in this transaction whose token is request_token, recipient receiver_wallet and value at least notional_uoa.

post/service/fulfillments/{id}/submit

Request

  • Base URL: https://api.instruxi.dev/api/v1/enforcer
  • URL: https://api.instruxi.dev/api/v1/enforcer/service/fulfillments/{id}/submit
  • Auth: none declared. Required headers: X-Tenant-ID

Path parameters

idstring required

reward fulfillment id

Headers

X-Tenant-IDstring required

tenant id

Request body

tx_hashstring

TxHash is the mined transaction that paid the row: 0x + 64 hex. Case is folded; it is stored lower-case.

Example request

{
  "tx_hash": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060"
}

Response

OK

successboolean

Example response

{
  "success": true
}

Changes

No recorded changes to this operation across all 1 revision of this API.