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.
Path parameters
Deposit id. Returned by GET /deposits.
Deposit id. Returned by GET /deposits.
Headers
API key for authentication (omit when sending Authorization)
API key for authentication (omit when sending Authorization)
Bearer platform token (e.g. forwarded by user-service). Takes precedence over x-api-key when both are present.
Bearer platform token (e.g. forwarded by user-service). Takes precedence over x-api-key when both are present.
API version identifier (e.g. "2026-04.amazon"). Optional today, will become required in a future release.
API version identifier (e.g. "2026-04.amazon"). Optional today, will become required in a future release.
Request body
Example request
{
"settlementLayer": "RELAY"
}Response
Deposit retry initiated