> ## 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.

# Close TED IN Reconciliation Gaps

> Use this endpoint to close every open TED IN reconciliation gap whose latch time falls in a window, after a person checked the JD `ExtratoFinanceiro` statement and found no message lost in that window. The automatic poller recovery clears the latch but leaves its gap open, because it does not prove that nothing was lost. This endpoint closes those gaps.

No money moves here. The `note` records a check done outside this system. `latchedTo` must not be in the future, and `latchedFrom` must not be after it. Equal bounds close one gap. The answer is the number of gaps closed, and it can be zero.

This is a tenant-wide administrative action. It requires the `transfers:resolve` permission and a user token. It does not require the `X-Organization-Id` header. In multi-tenant deployments it is scoped to the caller's resolved tenant database.



## OpenAPI

````yaml /pt/openapi/v3-current/ted.yaml post /v1/transfers/ted-in/reconciliation-gaps/close
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.5.1
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/reconciliation-gaps/close:
    post:
      tags:
        - Transfers API
      summary: Close TED IN Reconciliation Gaps
      description: >-
        Use this endpoint to close every open TED IN reconciliation gap whose
        latch time falls in a window, after a person checked the JD
        `ExtratoFinanceiro` statement and found no message lost in that window.
        The automatic poller recovery clears the latch but leaves its gap open,
        because it does not prove that nothing was lost. This endpoint closes
        those gaps.


        No money moves here. The `note` records a check done outside this
        system. `latchedTo` must not be in the future, and `latchedFrom` must
        not be after it. Equal bounds close one gap. The answer is the number of
        gaps closed, and it can be zero.


        This is a tenant-wide administrative action. It requires the
        `transfers:resolve` permission and a user token. It does not require the
        `X-Organization-Id` header. In multi-tenant deployments it is scoped to
        the caller's resolved tenant database.
      operationId: closeTEDInReconciliationGaps
      parameters:
        - $ref: '#/components/parameters/XIdempotencyKey'
      requestBody:
        required: true
        description: >-
          The window of latch times to close, and the note that records the
          check.
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/CloseReconciliationGapsRequest'
      responses:
        '200':
          description: Indicates that the open gaps in the window were closed.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/CloseReconciliationGapsResponse'
        '400':
          description: >-
            BTF-0001: missing idempotency key, invalid body, a missing bound,
            `latchedFrom` after `latchedTo`, `latchedTo` in the future, a `note`
            outside 10 to 500 characters, or a `note` that holds a control
            character other than TAB, LF, or CR.
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/ProblemDocument'
        '401':
          $ref: '#/components/responses/Unauthorized'
        '403':
          description: >-
            BTF-0405: the caller lacks the `transfers:resolve` permission.
            BTF-0406: the bearer token is not a person (a service account or a
            token of another type), so this by-hand write cannot be attributed
            to an operator. No grant fixes this; call the endpoint with a user
            token.
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/ProblemDocument'
        '409':
          description: >-
            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':
          description: 'BTF-9000: internal server error.'
          headers:
            X-Idempotency-Fenced:
              $ref: '#/components/headers/XIdempotencyFenced'
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/ProblemDocument'
        '503':
          description: >-
            BTF-9005, BTF-9007, BTF-9008: a dependency or the repository 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'
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:
    CloseReconciliationGapsRequest:
      type: object
      required:
        - latchedFrom
        - latchedTo
        - note
      properties:
        latchedFrom:
          type: string
          format: date-time
          description: The start of the window of latch times, inclusive.
          example: '2026-10-01T00:00:00Z'
        latchedTo:
          type: string
          format: date-time
          description: >-
            The end of the window of latch times, inclusive. It must not be in
            the future.
          example: '2026-10-31T23:59:59Z'
        note:
          type: string
          minLength: 10
          maxLength: 500
          description: The justification of the person who checked the statement.
          example: 'JD ExtratoFinanceiro checked: no message lost in October'
    CloseReconciliationGapsResponse:
      type: object
      properties:
        closed:
          type: integer
          description: The number of gaps closed. It can be zero.
          example: 293
    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/<code>`.
          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.<field>` or `query.<field>`.'
                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:
    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
    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.
  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 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.