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.
Replay outcome label. Unlike the poll cycle, replay does not check the operating-hours window and has no per-message cancellation, so it never returns skipped_outside_window or cancelled.
success, empty, skipped_busy, error "success"
Number of persisted backlog rows reprocessed during this pass.
x >= 02