> ## 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. # Timeline of the transfer transitions > Returns the timeline of a transfer: one entry for each status transition, in chronological order. Each entry has the instant, the source and target states, who caused the transition (`origin`: API, rail, STR, ledger, worker, operator, or system), the official reason, and the related identifier (for example, the `nuop` assigned at submission). When the transition has a milestone on the transfer (`reservedAt`, `submittedAt`, `settledAt`, and the others), the instant of the entry is that milestone, unless it would fall before the previous entry. In that case, the entry shows when TED Lerian recorded the transition, and the milestone stays on the transfer. This happens, for example, on a TED settled by reconciliation, whose `settledAt` is the instant the rail reported. So no entry shows before the entries that came before it. Use it for audit, customer support ("what happened to TED X?"), and to debug integrations. For the current state, `GET /v1/transfers/{transferId}` is enough. ## OpenAPI ````yaml /es/openapi/v3-current/ted-lerian.yaml get /v1/transfers/{transferId}/timeline 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](/es/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/transfers/{transferId}/timeline: get: tags: - Transfers summary: Timeline of the transfer transitions description: >- Returns the timeline of a transfer: one entry for each status transition, in chronological order. Each entry has the instant, the source and target states, who caused the transition (`origin`: API, rail, STR, ledger, worker, operator, or system), the official reason, and the related identifier (for example, the `nuop` assigned at submission). When the transition has a milestone on the transfer (`reservedAt`, `submittedAt`, `settledAt`, and the others), the instant of the entry is that milestone, unless it would fall before the previous entry. In that case, the entry shows when TED Lerian recorded the transition, and the milestone stays on the transfer. This happens, for example, on a TED settled by reconciliation, whose `settledAt` is the instant the rail reported. So no entry shows before the entries that came before it. Use it for audit, customer support ("what happened to TED X?"), and to debug integrations. For the current state, `GET /v1/transfers/{transferId}` is enough. operationId: getTransferTimeline parameters: - description: Transfer identifier in: path name: transferId required: true schema: description: Transfer identifier format: uuid type: string - $ref: '#/components/parameters/XRequestId' responses: '200': content: application/json: example: entries: - at: '2026-10-22T13:05:12Z' origin: API toStatus: CREATED - at: '2026-10-22T13:05:13Z' fromStatus: CREATED origin: LEDGER toStatus: RESERVED - at: '2026-10-22T13:05:14Z' fromStatus: RESERVED origin: RAIL reference: '87654321202610220000123' toStatus: SUBMITTED - at: '2026-10-22T13:05:41Z' fromStatus: SUBMITTED origin: STR reference: STR20261022000000123 toStatus: SETTLED resourceId: 6f1c2b3a-4d5e-4f60-8a9b-0c1d2e3f4a5b schema: $ref: '#/components/schemas/TimelineDTO' description: Timeline in chronological order, from creation to the current state. 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' '404': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- Resource does not exist in this institution, or the identifier is not in UUID format (`TED-0010`). headers: X-Request-Id: $ref: '#/components/headers/XRequestId' '422': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- Parameter outside the declared format (for example, a `date` that is not YYYY-MM-DD): a framework validation refusal (`TED-0002`, see `errors`). headers: X-Request-Id: $ref: '#/components/headers/XRequestId' '500': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- Unexpected failure (`TED-9000`). 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: >- Organization scope not configured for this installation (`TED-0080`): the read fails closed until the configuration exists. 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: TimelineDTO: additionalProperties: false description: >- Timeline of a transfer: each entry is a status transition with its origin, instant, and related reference. properties: entries: description: Transitions in chronological order. items: $ref: '#/components/schemas/TimelineEntryDTO' type: array resourceId: description: Identifier of the transfer. format: uuid type: string required: - resourceId - entries 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 TimelineEntryDTO: additionalProperties: false description: >- One status transition of the transfer. `origin` tells you who caused it (API, rail, STR, ledger, worker, operator, or system). properties: actor: description: Operator identity when origin=OPERATOR. type: string at: description: Instant (UTC) of the transition. format: date-time type: string fromStatus: description: >- TransferStatus value. Missing in the first transition and in entries rebuilt from a point in time. type: string origin: enum: - API - RAIL - STR - LEDGER - WORKER - OPERATOR - SYSTEM type: string reason: description: Official reason for the transition, verbatim. type: string reference: description: Related identifier (nuop, numCtrlStr, event id). type: string toStatus: description: TransferStatus value. type: string required: - at - toStatus - origin 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.