Retry a failed deposit by id
Re-drive one failed deposit through the settlement flow, addressing it by the stable id returned by GET /deposits. Authenticate with an x-api-key (write scope) or a Bearer platform token. Scoped to the caller’s tenant: an unknown id and another tenant’s id are both a 404. The deposit must be failed or rejected; operator-only states (ignored, delayed) are retryable through the admin endpoint only. Unlike POST /deposits/retry, the error code the deposit failed with does not gate the retry. Optionally pin the settlement layer — EVM only, refused for a Solana or HyperCore deposit rather than silently ignored. Omit the body entirely to retry without pinning a layer. Tron deposits are not retryable. A HyperCore deposit whose first leg already completed is refused with a 409. A 200 means the retry was accepted and re-driven, not that it settled.
Headers
API key for authentication (omit when sending Authorization)
"your-api-key"
Bearer platform token (e.g. forwarded by user-service). Takes precedence over x-api-key when both are present.
"Bearer eyJhbGciOi..."
API version identifier (e.g. "2026-04.amazon"). Optional today, will become required in a future release.
^\d{4}-\d{2}\.[a-z0-9]+$"2026-04.amazon"
Path Parameters
Deposit id. Returned by GET /deposits.
^\d+$"12345"
Body
Optional settlement-layer override for the re-drive (e.g. "ACROSS", "RELAY"). EVM deposits only; rejected for Solana. Omit to let the orchestrator pick.
1"RELAY"