> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# HTTP Retry Receipts and Reconciliation

> Preserve original HTTP request identity, inspect pending receipts, and reconcile verified outcomes without repeating a business mutation.

The Rust commerce HTTP layer stores retry receipts in the selected commerce database.
These are distinct from native governed command receipts and provider idempotency keys.
Back up the tenant database to preserve its business state and completed responses together.

## Keep the original request

Retain `Idempotency-Key`, route, exact request content, tenant/store and authentication context
before dispatch. Required-key routes return 428 when the key is missing; a reused key with a
changed fingerprint returns 422. Authentication and authorization precede replay.
Do not change keys after a lost response to make a request run again.

A pending receipt has `response_status = 0` and never automatically expires. The mutation
may already have committed even if the response could not be stored. Age, process restart,
or a later rejection does not prove rollback. Inspect the business/provider record first.

## Inspect pending work without changing it

From the source checkout, the native operator example opens an existing store read-only,
without creating it or running migrations:

```bash theme={null}
cargo run --locked -p stateset-db --example http_receipts -- \
  ./store.db list 'tenant:merchant'
```

Inspection is tenant-scoped and bounded to the oldest 1,000 pending summaries, including exact
reservation times. For a single-tenant store the empty tenant is explicit. Library pending
inspection exists on SQLite and PostgreSQL; do not use direct SQL deletion as a retry strategy.

## Reconcile a verified SQLite outcome

Stop the original worker and verify the business/provider result. Prepare operator-owned
`HttpReceiptResolution` JSON with original tenant, key, fingerprint, reservation time, verified
response and incident/evidence attribution. Preview first:

```bash theme={null}
cargo run --locked -p stateset-db --example http_receipts -- \
  ./store.db resolve ./resolution.json
# After independently stopping the worker and verifying the outcome:
cargo run --locked -p stateset-db --example http_receipts -- \
  ./store.db resolve ./resolution.json --apply --worker-stopped
```

Completion compares the exact pending identity and writes the verified response with a
required audit entry atomically. Stale or repeated resolution conflicts. Audit failure leaves
it pending. The helper does not rerun the mutation, delete the receipt, prove worker termination,
or verify external settlement. It is operator-only and outside the MCP catalog.

The audited helper is SQLite-specific; PostgreSQL has pending inspection and its existing
fingerprint-checked completion API. Scope, API and evidence must match the backend. Resume
clients only after reconciling the original outcome and confirming same-key behavior.

For HTTP authentication and tenant setup see [API hardening](/stateset-icommerce/stateset-icommerce-api-hardening).
For storage failure and restore see [backup/recovery](/stateset-icommerce/stateset-icommerce-backup-restore).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.