> ## 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. # Get scheduled payment > Returns one scheduled debit of the account named in X-Account-Id, in any status, by the `id` that an item of [List scheduled payments](/en/reference/interfaces/pix-lerian/pix-automatico/list-scheduled-payments) carries. Use it to read one debit again, for example after you cancel it or to follow its settlement, without paging the list. The response is the same item that the list returns. A debit that settled keeps the status `SCHEDULED`, and `settlement` carries the outcome of the latest settlement attempt; it is absent while no attempt exists. Unlike the list, this operation reads the primary database, so a cancellation or a settlement outcome that was just recorded shows on the next call. A debit that does not exist, was deleted, or belongs to an account other than X-Account-Id answers `404` (`PIX-0824`) in all three cases. An id that is not a UUID answers `400` (`PIX-0015`). ## OpenAPI ````yaml /en/openapi/v3-current/pix-lerian-pixauto.yaml get /payer/scheduled-payments/{scheduled_payment_id} openapi: 3.1.0 info: contact: name: Lerian Studio url: https://lerian.studio description: >- Pix Automático payer-facing API — deciding an authorization request raised by the receiving end, managing the payer-configurable parameters of a granted mandate, and revoking it (Guia de Implementação do Pix Automático v1.2 §3 and §6). ## Trust boundary This API is **machine-to-machine**. The caller is the client PSP's backend, authenticated with an application token; the token names that application and never one of its customers. The account therefore has to arrive in the request, and it does so in one of two shapes: most routes take it in the **`X-Account-Id`** header, the same header SPI, DICT and COB use for the same job, and the route that CREATES the resource the account belongs to takes `payerAccountId` in the body — `POST /v1/payer/authorization-requests/from-qr`, which opens a pending request for a mandate that does not exist yet. On that route, the account is part of what is being created rather than a scope on an existing resource, and a header beside the body field would be a second source for one value. Either way the value is the caller's **declaration** of which of its own customers it is acting for. **It is not proof that the end user controls that account, and this API cannot make it one.** Authenticating the payer and authorising its own customers against one another is the calling PSP's responsibility. What this end enforces is consistency: an absent header is 400 (PIX-0001) and a malformed account is 400 (PIX-0017 on the header, PIX-0003 in the body), and a resource that exists under a different account than the one named is **404**, not 403: the account is a predicate on the lookup, so this end never learns the resource exists elsewhere and cannot confirm it. Within one lookup, absence and a resource outside the selection get the same answer. license: name: Lerian Studio General License title: Pix Lerian — Pix Automático version: 1.2.0 servers: - url: https://api.example.com/pixauto/v1 description: >- Replace the example host with the URL provided during environment onboarding. security: - BearerAuth: [] tags: - description: >- Authorization requests raised by the receiving end and answered by the payer. A request is answered once. name: Payer Authorization Requests - description: Granted mandates. An authorization is managed for as long as it lives. name: Payer Authorizations - description: >- The payer's forward view of upcoming debits, the cancellation of one of them, and the release of a debit whose settlement attempt never got an outcome. Cancelling a debit leaves the authorization ACTIVE — it stops one charge, not the mandate. The operations are meant to be used together: the listing is the only place a client receives the scheduled_payment_id the others address. name: Payer Scheduled Payments paths: /payer/scheduled-payments/{scheduled_payment_id}: get: tags: - Payer Scheduled Payments summary: Get scheduled payment description: >- Returns one scheduled debit of the account named in X-Account-Id, in any status, by the `id` that an item of [List scheduled payments](/en/reference/interfaces/pix-lerian/pix-automatico/list-scheduled-payments) carries. Use it to read one debit again, for example after you cancel it or to follow its settlement, without paging the list. The response is the same item that the list returns. A debit that settled keeps the status `SCHEDULED`, and `settlement` carries the outcome of the latest settlement attempt; it is absent while no attempt exists. Unlike the list, this operation reads the primary database, so a cancellation or a settlement outcome that was just recorded shows on the next call. A debit that does not exist, was deleted, or belongs to an account other than X-Account-Id answers `404` (`PIX-0824`) in all three cases. An id that is not a UUID answers `400` (`PIX-0015`). operationId: getPayerScheduledPayment parameters: - description: >- Non-zero UUID of the payer account selected by the calling PSP. The PSP must authorize its end user for that account before calling this API. A resource outside the selected account returns 404; a read with no records returns an empty page. See the API overview for the complete trust boundary. example: 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d7e in: header name: X-Account-Id required: true schema: format: uuid not: const: 00000000-0000-0000-0000-000000000000 pattern: >- ^[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}$ type: string - description: >- Internal identifier of the scheduled debit, the id an item of GET /v1/payer/scheduled-payments carries, in ANY status. A debit under a different X-Account-Id is answered 404, not 403, so the caller cannot confirm that a debit exists elsewhere. in: path name: scheduled_payment_id required: true schema: description: >- Internal identifier of the scheduled debit, the id an item of GET /v1/payer/scheduled-payments carries, in ANY status. A debit under a different X-Account-Id is answered 404, not 403, so the caller cannot confirm that a debit exists elsewhere. examples: - 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40 format: uuid type: string responses: '200': content: application/json: example: amount: amount: '89.90' currency: BRL authorizationId: 01a044a8-f3bd-7488-a0dc-e8d4be4802be createdAt: '2026-09-01T12:00:00Z' endToEndId: E12345678202609101200a1b2c3d4e5f id: 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40 maximumAmountSnapshot: amount: '250.75' currency: BRL purpose: AGND receiver: name: Academia Corpo em Movimento Ltda taxId: type: CNPJ value: '11222333000181' recurrenceId: RR12345678202608276bca619e690 scheduledDate: '2026-09-10' settlement: concludedAt: '2026-09-10T12:00:04Z' endToEndId: E12345678202609101200a1b2c3d4e5f outcome: COMPLETED startedAt: '2026-09-10T12:00:01Z' status: SCHEDULED updatedAt: '2026-09-01T12:00:00Z' schema: $ref: '#/components/schemas/ScheduledPaymentItem' description: The scheduled debit, in any status. '400': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- Malformed or invalid path, header or query input (PIX-0001, PIX-0003, PIX-0015, PIX-0017, PIX-0020, plus operation-specific PIX codes). '404': content: {} description: >- No scheduled debit with that identifier is reachable by the caller (PIX-0824). '500': content: application/json: example: code: PIX-0000 message: >- The server encountered an unexpected error. Please try again later. title: Internal Server Error schema: $ref: '#/components/schemas/Error' description: >- Unexpected internal failure (PIX-0000). Details never travel in the envelope. default: content: application/json: schema: $ref: '#/components/schemas/Error' description: >- Any other error returned by the handler uses the same PIX error envelope. The HTTP status and code identify the concrete failure. In multi-tenant deployments the tenant layer can also refuse before the handler runs -- for example 404 TENANT_NOT_FOUND or 503 SERVICE_UNAVAILABLE -- with its own {code,title,message} body; branch on the HTTP status. components: schemas: ScheduledPaymentItem: additionalProperties: false properties: amount: $ref: '#/components/schemas/Money' description: Amount that will be debited. authorizationId: description: >- Mandate the debit was scheduled under. ABSENT rather than null when the debit carries none, as on a same-day resend (purpose RIFL) answering a failed attempt. format: uuid type: string createdAt: format: date-time type: string id: description: >- Internal identifier of the scheduled debit. Pass it as {scheduled_payment_id} to the cancel operation, or to the operation that reads one debit. format: uuid type: string maximumAmountSnapshot: $ref: '#/components/schemas/Money' description: >- The maximum amount in force AT SCHEDULING TIME, written once and never updated — a later change to the mandate does not reach this debit (Guia v1.2 §6.1). Absent when no ceiling was in force. purpose: description: >- Why the debit exists: AGND a scheduled collection, NTAG a post-due retry, RIFL a same-day resend after a failed attempt. enum: - AGND - NTAG - RIFL type: string recurrenceId: description: >- BACEN idRec of the recurrence the debit belongs to. ABSENT rather than empty on a debit that belongs to no recurrence. type: string scheduledDate: description: >- Business date the debit settles on, after business-day and local-holiday adjustment. A calendar date (YYYY-MM-DD) with no time of day and no zone. format: date type: string status: description: >- Lifecycle state of the debit. Only a SCHEDULED debit can be cancelled; the cancellation route answers 409 for any other state. Only SCHEDULED and CANCELLED are produced: a debit that settled keeps reading SCHEDULED, and settlement.outcome carries the payment result. enum: - SCHEDULED - DISPATCHING - SETTLED - FAILED - CANCELLED - RECONCILING type: string updatedAt: format: date-time type: string settlement: $ref: '#/components/schemas/ScheduledPaymentSettlement' description: >- Payment outcome of the debit, read from its LATEST settlement attempt. ABSENT rather than null while no attempt exists. It is the field that says whether the debit was paid: status keeps the scheduling lifecycle and a debit that settled keeps reading SCHEDULED. The listing reads a replica, so an attempt that has just concluded can still read PROCESSING there for a moment; GET /v1/payer/scheduled-payments/{scheduled_payment_id} reads the primary. The settlement_* events push only negative or pending outcomes; a COMPLETED settlement emits no event and is seen only by re-reading the debit, through the listing or the individual read (or the account's outgoing Pix). endToEndId: description: >- End-to-end identifier (IdFimAFim) the debit settles under, available FROM SCHEDULING, before any settlement attempt. On a debit scheduled from a receiving PSP's payment instruction (pain.013) it is the identifier that PSP minted; it is reused byte for byte on the settlement order (pacs.008), so it equals settlement.endToEndId once an attempt exists. On a debit scheduled from an Open Finance payment initiation it is the endToEndId the initiator sent. Absent only if the debit's origin could not be read. examples: - E12345678202610101200b2c3d4e5f6a maxLength: 32 minLength: 32 type: string receiver: $ref: '#/components/schemas/ReceiverBody' description: >- Who the debit pays: name and CPF/CNPJ, the same shape as recurrence.receiver on the mandate surfaces. On a debit scheduled from a payment instruction it is the receiver of the recurrence the debit belongs to; on a debit scheduled from an Open Finance payment initiation, the creditor of the consent. Absent when neither is recorded. required: - id - amount - scheduledDate - purpose - status - createdAt - updatedAt type: object Error: additionalProperties: false properties: code: examples: - PIX-0142 type: string fields: additionalProperties: type: string type: object headers: additionalProperties: type: string type: object message: examples: - claim_id is required type: string paths: additionalProperties: type: string type: object query_params: additionalProperties: type: string type: object raw: $ref: '#/components/schemas/RawError' title: examples: - Invalid Claim Request type: string required: - code - title - message type: object Money: additionalProperties: false properties: amount: description: >- Decimal string, positive, with at most two fractional digits and at most thirteen integer digits. A string, not a float — binary floating point cannot represent every centavo exactly, and this is a money path. Trailing zeros are not padded: 150.00 and 150 are the same amount. examples: - '149.95' pattern: ^(0\.([1-9][0-9]?|0[1-9])|[1-9][0-9]{0,12}(\.[0-9]{1,2})?)$ type: string currency: description: Pix settles in BRL only. enum: - BRL examples: - BRL type: string required: - amount - currency type: object ScheduledPaymentSettlement: additionalProperties: false properties: concludedAt: description: >- When the attempt reached COMPLETED or REJECTED. RFC 3339, UTC. Present if and only if outcome is COMPLETED or REJECTED. examples: - '2026-09-10T12:00:04Z' format: date-time type: string endToEndId: description: >- End-to-end identifier of this attempt's settlement order (pacs.008). It is NOT minted per attempt: it is the debit's own identifier, the one the item's top-level endToEndId carries from scheduling, reused byte for byte. It does not prove the order reached the rail: an order still being prepared (published as PROCESSING) or one REJECTED with a failureCategory other than REJECTED_BY_RAIL never did. examples: - E12345678202609101200a1b2c3d4e5f maxLength: 32 minLength: 32 type: string failureCategory: description: >- Why a REJECTED attempt failed. Present only on REJECTED, and only when a cause was recorded. Only REJECTED_BY_RAIL implies the order reached the rail. enum: - INSUFFICIENT_FUNDS - INSUFFICIENT_LIMIT - OPERATIONAL_FAILURE - REJECTED_BY_RAIL examples: - INSUFFICIENT_FUNDS type: string outcome: description: >- Outcome of the latest settlement attempt. PROCESSING while the order is being placed or the rail has not answered; COMPLETED once the money moved; REJECTED when the attempt failed (failureCategory says why, when recorded); UNKNOWN when the order was dispatched and its fate is not yet known. enum: - PROCESSING - COMPLETED - REJECTED - UNKNOWN examples: - COMPLETED type: string startedAt: description: >- When the attempt was recorded, before the order was sent. RFC 3339, UTC. examples: - '2026-09-10T12:00:01Z' format: date-time type: string required: - outcome - endToEndId - startedAt type: object ReceiverBody: additionalProperties: false properties: name: description: Name of the receiving user, as the payer is shown it. examples: - Academia Corpo em Movimento Ltda type: string taxId: $ref: '#/components/schemas/TaxIDBody' description: CPF or CNPJ of the receiving user. required: - name - taxId type: object RawError: additionalProperties: false properties: message: examples: - upstream provider returned 503 type: string status: format: int64 type: integer required: - status - message type: object TaxIDBody: additionalProperties: false properties: type: description: Which document value carries. enum: - CPF - CNPJ examples: - CNPJ type: string value: description: 'The document, digits only: 11 for a CPF, 14 for a CNPJ.' examples: - '11222333000181' type: string required: - type - value type: object securitySchemes: BearerAuth: bearerFormat: JWT description: JWT bearer token issued by the identity provider. scheme: bearer type: http ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.