Replay TED IN Backlog
Use this endpoint to force one immediate replay pass over persisted, unprocessed JD inbound messages for the current tenant. Unlike /ted-in/poll, this route does not read JD’s destructive queue — it only reprocesses durable backlog rows already persisted locally.
Use the X-Idempotency header for guaranteed deduplication.
Authorizations
JWT Bearer token authentication. The tenantId is derived from the bearer token or authenticated request context and is not supplied through X-Organization-Id.
Headers
Midaz organization scope for the request, used for downstream CRM, Fees, and Midaz calls. Required on org-scoped transfer routes in every deployment mode; a missing or non-UUID value returns 400. This is not the tenant identifier — tenantId is derived from the bearer JWT or authenticated context, never from this header. Background workers (TED IN poller, reconciliation) have no request header and, in single-tenant mode, fall back to the deployment's ORGANIZATION_ID env.
Required idempotency key for safe retries. Use a UUID v4 or unique business identifier. If the same key is sent again and the original request was already processed, the cached response is returned.
See Retries and idempotency for details.
255Response
Indicates that the replay pass completed. The outcome field reports the cycle result and replayed is the number of backlog rows reprocessed.
The replay outcome, for example success, empty, or held. held means that the pass replayed nothing and left at least one inbound credit held.
"success"
Number of persisted backlog rows reprocessed during this pass.
x >= 02
The number of inbound credits that this pass left held, because no ledger binding covers them. They are neither credited nor failed.
x >= 00
The number of messages that another process is already carrying, so this pass left them alone. They are replayed when that claim expires.
x >= 00

