> ## 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. # Trigger an on-demand reconciliation run > Starts a reconciliation cycle on demand. This is the same cycle that the worker runs periodically: it queries the rail about the transfers in `AWAITING_RECONCILIATION` and applies the conclusive outcomes. Use it after a rail outage, or when operations do not want to wait for the next cycle. The response is 202 with the `runId` of the scheduled cycle. Processing is asynchronous, and its effects appear in the transfers and in the operations queue. Only one cycle runs at a time: if a cycle is already running, the response is 409 `TED-0015`. `X-Idempotency` is required (no body). Check `X-Idempotency-Replayed` in the response to tell a new cycle from a replay. ## OpenAPI ````yaml /en/openapi/v3-current/ted-lerian.yaml post /v1/reconciliation/runs openapi: 3.1.0 info: description: >- API of **TED Lerian**, the interface over Lerian SPB. Your institution uses it to send TEDs, make internal transfers, track incoming TEDs, and operate returns, queues, and policy on its Midaz ledger. The [API overview](/en/reference/interfaces/ted-lerian/ted-lerian-api-overview) gives the concepts, the roles, and the conventions. title: TED Lerian API version: v1.0.0 servers: - url: https://api.example.com description: >- Replace the example host with the URL provided during environment onboarding. security: - BearerAuth: [] tags: - description: >- Outgoing TEDs and internal transfers: fee quote, creation, query, timeline, and cancellation. Every integration starts here. name: Transfers - description: >- Incoming TEDs from other institutions: query, timeline, and operator actions (full return and manual review resolution). name: Incoming Transfers - description: >- STR participant list, to resolve COMPE code ↔ ISPB and validate the destination bank before you create a transfer. name: Participants - description: >- Back office: operations queue, inconsistency findings between the ledger and the STR, reviews of rail facts, held returns, and manual unblock with evidence. name: Reconciliation - description: >- Operations dashboard: daily aggregates, regulatory deadlines (30/60/60 min), and the closing balance that the STR reported. name: Operations - description: >- Institution configuration (editor): operating window and cut-off, usage limits, holiday calendar, and ISPB → organization bindings. name: Policy paths: /v1/reconciliation/runs: post: tags: - Reconciliation summary: Trigger an on-demand reconciliation run description: >- Starts a reconciliation cycle on demand. This is the same cycle that the worker runs periodically: it queries the rail about the transfers in `AWAITING_RECONCILIATION` and applies the conclusive outcomes. Use it after a rail outage, or when operations do not want to wait for the next cycle. The response is 202 with the `runId` of the scheduled cycle. Processing is asynchronous, and its effects appear in the transfers and in the operations queue. Only one cycle runs at a time: if a cycle is already running, the response is 409 `TED-0015`. `X-Idempotency` is required (no body). Check `X-Idempotency-Replayed` in the response to tell a new cycle from a replay. operationId: triggerReconciliationRun parameters: - description: >- Replay window of the idempotency key, in seconds. Default 300 (5 minutes) when missing or invalid. Values outside 30 s to 7 days are adjusted to these limits. Only the value of the FIRST request for a key counts. A change to X-TTL on retries has no effect. The window sets how long the response is replayed. in: header name: X-TTL schema: minimum: 1 type: integer - description: >- Idempotency key that the integrator creates (1 to 128 printable ASCII characters, no spaces; we recommend a UUID). Required on every operation with an effect. Send the SAME key again when you retry a call that failed because of a timeout or network error. Same key + same body returns the original response with `X-Idempotency-Replayed: true` and no new effect. Same key + different body responds 422 `TED-0012`. Same key still in processing responds 409 `TED-0013` (retry after `Retry-After`). Missing or in the wrong format: 400 `TED-0011`. in: header name: X-Idempotency required: true schema: type: string - $ref: '#/components/parameters/XRequestId' responses: '202': content: application/json: example: requestedAt: '2026-10-22T13:30:00Z' runId: c9f5a1b3-4d6e-4f80-9b2c-3d5e7f9a1b2c status: SCHEDULED schema: $ref: '#/components/schemas/ReconciliationRunResponse' description: >- Run scheduled. `runId` identifies the cycle. If `X-Idempotency-Replayed: true`, this is the replay of an earlier trigger. headers: X-Idempotency-Replayed: description: >- `true` when this response is the replay of a previous request with the same `X-Idempotency` (no new effect occurred). Absent when the request produced a new effect. Always check this header: the HTTP status and the body are identical in both cases. schema: type: boolean X-Request-Id: $ref: '#/components/headers/XRequestId' '400': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: '`X-Idempotency` missing or in the wrong format (`TED-0011`).' headers: X-Request-Id: $ref: '#/components/headers/XRequestId' '401': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: 'Not authenticated: token missing, invalid, or expired (`TED-0070`).' headers: X-Request-Id: $ref: '#/components/headers/XRequestId' '403': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- No permission: the token's role does not authorize this action, or the product license is not valid for the organization (`TED-0071`). headers: X-Request-Id: $ref: '#/components/headers/XRequestId' '409': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- A reconciliation cycle is already running (`TED-0015`), or a request with the same `X-Idempotency` is still in progress (`TED-0013`; try again after `Retry-After`). headers: X-Request-Id: $ref: '#/components/headers/XRequestId' '422': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- A validation or business rule failed: invalid fields (`TED-0002`, see `errors`), or `X-Idempotency` reused with a different body (`TED-0012`). Refusals specific to the operation are in its description. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' '500': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- Unexpected failure (`TED-9000`). Retry with the SAME `X-Idempotency`. If it continues, contact support and give the `X-Request-Id` of the response. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' '503': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Institution configuration missing (`TED-0080`). headers: X-Request-Id: $ref: '#/components/headers/XRequestId' components: parameters: XRequestId: description: >- Correlation identifier of this request (UUID). Optional: when you omit it, or when the value is not a well-formed UUID, the platform creates a UUID and returns it in the X-Request-Id header of the response. The resolved identifier goes to the logs, spans, and audit events of this request. Keep it to open a support ticket. in: header name: X-Request-Id schema: format: uuid type: string schemas: ReconciliationRunResponse: additionalProperties: false description: >- Reconciliation run scheduled on demand. Processing is asynchronous; track the effects in the queues and in the affected resources. properties: requestedAt: description: Timestamp (UTC) of the request. format: date-time type: string runId: description: Identifier of the scheduled cycle. format: uuid type: string status: description: Status of the cycle at the moment of the response. enum: - SCHEDULED - RUNNING - COMPLETED type: string required: - runId - status - requestedAt type: object Detail: additionalProperties: true description: >- Standard error body (RFC 9457, `application/problem+json`) for every `/v1` operation. Use `code` (TED-NNNN) to handle the error in code, `detail` for the readable message, and `errors` for the invalid fields of a 422. The `X-Request-Id` of the response identifies the occurrence for support. properties: code: description: >- Stable, machine-readable domain error code scoped to the emitting service (format: -NNNN). type: string detail: description: >- A human-readable explanation specific to this occurrence of the problem. examples: - Property foo is required but is missing. type: string errors: description: Optional list of individual error details items: $ref: '#/components/schemas/ErrorDetail' type: - array - 'null' instance: description: >- A URI reference that identifies the specific occurrence of the problem. examples: - https://example.com/error-log/abc123 format: uri type: string status: description: HTTP status code examples: - 400 format: int64 type: integer title: description: >- A short, human-readable summary of the problem type. This value should not change between occurrences of the error. examples: - Bad Request type: string type: default: about:blank description: A URI reference to human-readable documentation for the error. examples: - https://example.com/errors/example format: uri type: string upstream: $ref: '#/components/schemas/Upstream' description: >- RFC 9457 extension member: the error a proxied third-party provider reported. Absent unless the emitting service explicitly surfaced one. type: object ErrorDetail: additionalProperties: false description: >- An invalid field inside a validation error: where it is (`location`), what is wrong (`message`), and the value received. properties: location: description: >- Where the error occurred, e.g. 'body.items[3].tags' or 'path.thing-id' type: string message: description: Error message text type: string value: description: The value at the given location type: object Upstream: additionalProperties: false description: >- Error reported by an upstream system (ledger or rail), when the service chooses to expose it. Absent in most errors. properties: code: description: The upstream provider's own error code, verbatim. examples: - E4001 type: string message: description: >- The upstream provider's own error message, verbatim (bounded, never its raw response body). examples: - account not found at provider type: string type: object headers: XRequestId: description: >- Echo of the request X-Request-Id: the value that the client sent, or the UUID that the platform generated when the client sent none. Present in every response, success or error. schema: format: uuid type: string securitySchemes: BearerAuth: bearerFormat: JWT description: >- JWT token that the Lerian Access Manager issues for your institution. Send it in `Authorization: Bearer ` on every call (except the public health probes). The tenant never comes from the body, the query, or the path. Each operation requires a role with the matching permission (see the API overview). Without it, 403 `TED-0071`. Missing, invalid, or expired token: 401 `TED-0070`. scheme: bearer type: http ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.