> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Resume TED IN Poller > Use this endpoint to clear the fail-closed at-most-once receive latch and re-arm a latched or dead TED IN poller without restarting the pod. This is a higher-privilege operator endpoint than `/ted-in/poll` because it re-opens JD destructive-read consumption. Reach for it only when auto-recovery cannot revive the poller — a panicked multi-tenant child or a single-tenant poller past the panic hard-cap. Resume never bypasses the money-path durable-gap gate. When the live receive-state-unknown latch is set, the current latch's reconciliation-gap row must be durable before the poller resumes; otherwise the request is refused with `409` and the poller stays dead. Verify the pending gap with [List TED IN Reconciliation Gaps](/pt/reference/interfaces/ted-jd/list-ted-in-reconciliation-gaps) before calling resume. The optional body `{acknowledge, note}` additionally marks the current latch's reconciliation gap resolved and stamps an operator annotation on it. `acknowledge` defaults to `false`, leaving the gap OPEN so it remains visible for review. A healthy, not-latched poller returns `200` with `resumed: false` and `reason: "not_latched"` — the call is a safe idempotent no-op. Same-key retries replay the cached response. The route is organization-independent and does not require the `X-Organization-Id` header — the tenant is resolved from the authenticated context. In multi-tenant deployments, an inactive tenant is rejected with `503`. ## OpenAPI ````yaml /pt/openapi/v3-current/ted.yaml post /v1/transfers/ted-in/resume openapi: 3.0.3 info: title: Bank Transfer (TED) Plugin API description: >- Complete API for Brazilian bank transfers (TED OUT, TED IN, P2P) through the Lerian platform, including transfer initiation, processing, status tracking, cancellation, and returns. version: 3.4.0 servers: - url: https://api.example.com description: >- Replace the example host with the URL provided during environment onboarding. security: - BearerAuth: [] - OAuth2ClientCredentials: - api - OAuth2Password: - api tags: - name: Transfers API description: >- Endpoints for initiating, processing, tracking, cancelling, and returning transfers. - name: Webhooks description: >- Endpoints for registering and managing tenant-scoped webhook subscriptions for transfer events. - name: Webhook DLQ description: Endpoints for inspecting and retrying webhook dead-letter queue messages. paths: /v1/transfers/ted-in/resume: post: tags: - Transfers API summary: Resume TED IN Poller description: >- Use this endpoint to clear the fail-closed at-most-once receive latch and re-arm a latched or dead TED IN poller without restarting the pod. This is a higher-privilege operator endpoint than `/ted-in/poll` because it re-opens JD destructive-read consumption. Reach for it only when auto-recovery cannot revive the poller — a panicked multi-tenant child or a single-tenant poller past the panic hard-cap. Resume never bypasses the money-path durable-gap gate. When the live receive-state-unknown latch is set, the current latch's reconciliation-gap row must be durable before the poller resumes; otherwise the request is refused with `409` and the poller stays dead. Verify the pending gap with [List TED IN Reconciliation Gaps](/pt/reference/interfaces/ted-jd/list-ted-in-reconciliation-gaps) before calling resume. The optional body `{acknowledge, note}` additionally marks the current latch's reconciliation gap resolved and stamps an operator annotation on it. `acknowledge` defaults to `false`, leaving the gap OPEN so it remains visible for review. A healthy, not-latched poller returns `200` with `resumed: false` and `reason: "not_latched"` — the call is a safe idempotent no-op. Same-key retries replay the cached response. The route is organization-independent and does not require the `X-Organization-Id` header — the tenant is resolved from the authenticated context. In multi-tenant deployments, an inactive tenant is rejected with `503`. operationId: resumeTEDInPoller parameters: - $ref: '#/components/parameters/XIdempotencyKey' requestBody: required: false description: >- Optional resume options. An empty body re-arms the poller and leaves the reconciliation gap open. content: application/json: schema: $ref: '#/components/schemas/TEDInResumeRequest' examples: rearmOnly: summary: Re-arm the poller, leave the gap open value: {} acknowledgeGap: summary: Re-arm and mark the current gap resolved value: acknowledge: true note: verified against the JD cabine; no inbound message lost responses: '200': description: >- Indicates that the resume attempt completed. `resumed` is `true` when a latched or dead poller was re-armed and `false` for the healthy no-op. `gapResolved` is `true` only when `acknowledge` was requested AND the gap row was successfully marked resolved. `reason` is the state resumed from (`receive_state_unknown`, `panic`, `auth_failure`) or `not_latched` for the no-op. content: application/json: schema: $ref: '#/components/schemas/TEDInResumeResponse' examples: resumed: summary: Latched poller re-armed value: resumed: true gapResolved: false reason: receive_state_unknown tenantId: 11111111-1111-1111-1111-111111111111 notLatched: summary: Healthy no-op value: resumed: false gapResolved: false reason: not_latched '400': $ref: '#/components/responses/BadRequest' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' '409': description: >- BTF-0108: resume refused. The receive-state-unknown latch has no durable reconciliation gap yet, so the poller stays dead. Retry after the gap row is persisted. BTF-0016: a request under this `X-Idempotency` key still holds the in-flight lease, because it is still running or because it already ended 5xx and recorded no outcome. `Retry-After` carries a poll interval, not the lease. While the first request is still running, resend the identical request after that interval; the answer replays from the first request as soon as it finishes. If an earlier request under this key answered 5xx without `X-Idempotency-Fenced: true`, no answer will ever be served from it: stop resending, read the resource this route acts on, and send the work under a new `X-Idempotency` key only if it did not land. The detail also names the 15-minute bound after which the lease lapses and a resend runs the work a second time; a poll still unanswered by then ends the same way. BTF-0018: the request under this `X-Idempotency` key already completed, and its response was too large to store for replay. Read the resource. Do not resend under a new key, because that runs the work a second time. This answer carries no `Retry-After`, because no wait produces the missing receipt. headers: Retry-After: $ref: '#/components/headers/RetryAfter' content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' '422': $ref: '#/components/responses/IdempotencyKeyRefused' '429': $ref: '#/components/responses/RateLimitExceeded' '500': $ref: '#/components/responses/IdempotentInternalServerError' '503': description: >- BTF-9005: a dependency is unavailable. BTF-9000: the idempotency store was unavailable before the handler ran, so nothing ran. Send the same request again under the same `X-Idempotency` key. BTF-0019: the work under this `X-Idempotency` key ran, and neither its response nor its outcome fence could be stored, so the key protects nothing and a resend can run the operation a second time. Read the resource before you send anything else. BTF-0020: the work under this `X-Idempotency` key ran and its response could not be stored for replay, but the key is still held. This answer is not the outcome of that work. Read the resource, and resend under a new key only if the work did not land. headers: X-Idempotency-Fenced: $ref: '#/components/headers/XIdempotencyFenced' content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' '504': $ref: '#/components/responses/IdempotentGatewayTimeout' components: parameters: XIdempotencyKey: name: X-Idempotency in: header required: true description: >- Required idempotency key for safe retries. Use a UUID v4 or a unique business identifier, made of letters, digits, `.`, `_`, and `-`. If the same key is sent again and the original request was already processed, the cached response is returned. See [Retries and idempotency](/pt/reference/retries-idempotency) for details. schema: type: string maxLength: 255 pattern: ^[a-zA-Z0-9._-]+$ example: 019c96a0-aa10-7abc-d1e2-8c9d0e1f2a3b schemas: TEDInResumeRequest: type: object description: >- Optional body for a TED IN poller resume. All fields are optional; an empty body re-arms the poller and leaves the reconciliation gap open. properties: acknowledge: type: boolean default: false description: >- When `true`, mark the current latch's reconciliation gap resolved after the poller is re-armed. Defaults to `false` so the gap stays OPEN and remains visible for review. example: false note: type: string maxLength: 500 description: >- Operator annotation stamped onto the resolved gap when `acknowledge` is `true`. Ignored otherwise. example: verified against the JD cabine; no inbound message lost TEDInResumeResponse: type: object required: - resumed - gapResolved - reason properties: resumed: type: boolean description: >- `true` when a latched or dead poller was re-armed; `false` for the healthy no-op. example: true gapResolved: type: boolean description: >- `true` only when `acknowledge` was requested AND the gap row was successfully marked resolved. example: false reason: type: string enum: - receive_state_unknown - panic - auth_failure - not_latched description: >- The poller state that was resumed from. `not_latched` indicates the idempotent no-op. example: receive_state_unknown tenantId: type: string format: uuid description: Resolved tenant identifier. Omitted in single-tenant deployments. example: 11111111-1111-1111-1111-111111111111 ProblemDocument: type: object description: >- The RFC 9457 problem document that the service answers every error with, on `application/problem+json`. Route-specific members (for example `refusalCode`, `transactionId`, `ledgerStatus`, `systemplaneKey`) appear flat at the top level beside these. additionalProperties: true required: - type - title - status - detail - code - requestId - service - category properties: type: type: string description: >- A URI that names the error code: `https://errors.lerian.studio/v1/`. example: https://errors.lerian.studio/v1/BTF-0200 title: type: string description: The HTTP status text. example: Not Found status: type: integer description: The HTTP status code. example: 404 detail: type: string description: A human-readable explanation of this occurrence. example: transfer not found instance: type: string description: The trace ID of this request, when one was recorded. example: 4bf92f3577b34da6a3ce929d0e0e4736 errors: type: array description: Each rejected field. Present on field validation errors only. items: type: object properties: message: type: string description: Why the value was rejected. example: transferId must be a valid UUID location: type: string description: 'Where the value sits: `body.` or `query.`.' example: body.senderAccountId code: type: string description: The stable BTF error code. example: BTF-0200 upstream: type: object description: >- The error that an upstream provider (JD SPB, Midaz) reported. Absent unless surfaced. properties: code: type: string description: The provider's own error code, verbatim. example: AAC90 message: type: string description: The provider's own error message, bounded. example: Assinatura invalida requestId: type: string description: The request correlation ID. Present even when empty. example: 6d3e2a68-1f2b-4c3d-9e4f-5a6b7c8d9e0f service: type: string description: The system that produced the error. example: plugin category: type: string description: The machine-readable error category. example: deterministic responses: BadRequest: description: Indicates that the request contains invalid input. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' examples: invalidInput: summary: Validation error value: type: https://errors.lerian.studio/v1/BTF-0001 title: Bad Request status: 400 detail: invalid request body code: BTF-0001 category: deterministic requestId: 6d3e2a68-1f2b-4c3d-9e4f-5a6b7c8d9e0f service: plugin Unauthorized: description: Indicates that the request is missing a valid authentication token. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' examples: unauthorized: summary: Missing authorization value: type: https://errors.lerian.studio/v1/BTF-0401 title: Unauthorized status: 401 detail: Missing Token code: BTF-0401 category: plugin requestId: 6d3e2a68-1f2b-4c3d-9e4f-5a6b7c8d9e0f service: plugin Forbidden: description: >- Indicates that the caller is authenticated but lacks permission for this operation. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' examples: permissionDenied: summary: Caller lacks permission value: type: https://errors.lerian.studio/v1/BTF-0405 title: Forbidden status: 403 detail: >- the credential is not allowed to perform transfers:create on this request code: BTF-0405 category: plugin requestId: 6d3e2a68-1f2b-4c3d-9e4f-5a6b7c8d9e0f service: plugin IdempotencyKeyRefused: description: >- BTF-0014: an earlier request under this `X-Idempotency` key answered 5xx, so the key is fenced for the retention window. Read the resource and, only if the work did not land, send the identical request under a new key. BTF-0015: this service cannot read the idempotency record under this key. The remedy is the same. BTF-0017: this `X-Idempotency` key was already used for a different request. A repeat must be byte-identical, and a new request needs its own new key. BTF-0017 is decided before BTF-0014, so a fenced key resent with a changed body gets BTF-0017. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' RateLimitExceeded: description: >- Indicates that the rate limit has been exceeded. Retry after the number of seconds specified in the Retry-After header. headers: Retry-After: description: Seconds until rate limit resets schema: type: integer example: 60 content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' examples: rateLimitExceeded: summary: Too many requests value: type: https://errors.lerian.studio/v1/BTF-0429 title: Too Many Requests status: 429 detail: Rate limit exceeded code: BTF-0429 category: rate_limit requestId: 6d3e2a68-1f2b-4c3d-9e4f-5a6b7c8d9e0f service: plugin description: > Rate-limit responses use the dedicated `BTF-0429` code with the `rate_limit` category. Clients should back off using the HTTP status `429` and the `Retry-After` header. IdempotentInternalServerError: description: Indicates that an unexpected internal error occurred. headers: X-Idempotency-Fenced: $ref: '#/components/headers/XIdempotencyFenced' content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' examples: internalError: summary: Internal error value: type: https://errors.lerian.studio/v1/BTF-9000 title: Internal Server Error status: 500 detail: Internal server error code: BTF-9000 category: plugin requestId: 6d3e2a68-1f2b-4c3d-9e4f-5a6b7c8d9e0f service: plugin IdempotentGatewayTimeout: description: >- Indicates that the operation did not complete before the request deadline. headers: X-Idempotency-Fenced: $ref: '#/components/headers/XIdempotencyFenced' content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDocument' headers: RetryAfter: description: The number of seconds to wait before you send the request again. schema: type: integer XIdempotencyFenced: description: >- `true` when this 5xx fenced the `X-Idempotency` key, so a resend is refused with 422 BTF-0014. `false` when the fence write itself failed and only the in-flight lease holds the key, so a resend is refused with 409 BTF-0016 until that lease lapses. On a 503 BTF-0019, `false` means the handler succeeded and both its receipt and its fence were lost. The header is absent when nothing fenced the key. On a 500 raised by a panic, the protection of the key is unknown: read the resource and reconcile before you resend. On a 503 BTF-9000 answered while the idempotency store was down before the handler, nothing ran: send the same request again under the same key. schema: type: string securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- JWT Bearer token authentication. The tenantId is derived from the bearer token or authenticated request context and is not supplied through X-Organization-Id. OAuth2ClientCredentials: type: oauth2 flows: clientCredentials: tokenUrl: /v1/login/oauth/access_token scopes: api: TED transfer API access OAuth2Password: type: oauth2 flows: password: tokenUrl: /v1/login/oauth/access_token scopes: api: TED transfer API access ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.