> ## 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. # List scheduled debits > Returns the payer's scheduled-debit lifecycle for the account — the "consulta e gerenciamento de pagamentos agendados" of Guia v1.2 §6.4. It is NOT a forward-only view: a debit stays listed after it leaves SCHEDULED, so SETTLED and CANCELLED entries appear beside the ones still to come. A payer asking why a charge did not happen needs the cancelled row, and the cancellation route needs the id only this listing returns. An empty page means that the account named in X-Account-Id has no scheduled debit. This is the ONLY operation that returns a scheduled debit's id, and POST /v1/payer/scheduled-payments/{scheduled_payment_id}/cancel needs that id. Integrate the two together: list, then cancel by the id an item carries. Each item carries maximumAmountSnapshot — the ceiling in force when the debit was SCHEDULED, written once and never updated — so a payer who has since changed the ceiling can see why an existing debit still reflects the old one. Returning it here is the payer's own authenticated channel; Guia v1.2 §6.1 bars sharing it with the RECEIVING user and their PSP, which this surface is not. Ordering is by scheduledDate and then by id, which is also what the cursor resumes on — not the write instant, unlike the three sibling listings. authorizationId is absent on a debit scheduled without a mandate (purpose RIFL), and maximumAmountSnapshot is absent when no ceiling was in force; neither absence is an error. Paging is by cursor. On the last page next_cursor is null, never an empty string. ## OpenAPI ````yaml /en/openapi/v3-current/pix-lerian-pixauto.yaml get /payer/scheduled-payments 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: ten routes take it in the **`X-Account-Id`** header, the same header SPI, DICT and COB use for the same job, and `POST /v1/payer/authorization-requests/from-qr` takes `payerAccountId` in the body — that route creates a pending request for a mandate that does not exist yet, so 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.0.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, and the cancellation of one of them. Cancelling a debit leaves the authorization ACTIVE — it stops one charge, not the mandate. The two operations are meant to be used together: the listing is the only place a client receives the scheduled_payment_id the cancellation addresses. name: Payer Scheduled Payments paths: /payer/scheduled-payments: get: tags: - Payer Scheduled Payments summary: List scheduled debits description: >- Returns the payer's scheduled-debit lifecycle for the account — the "consulta e gerenciamento de pagamentos agendados" of Guia v1.2 §6.4. It is NOT a forward-only view: a debit stays listed after it leaves SCHEDULED, so SETTLED and CANCELLED entries appear beside the ones still to come. A payer asking why a charge did not happen needs the cancelled row, and the cancellation route needs the id only this listing returns. An empty page means that the account named in X-Account-Id has no scheduled debit. This is the ONLY operation that returns a scheduled debit's id, and POST /v1/payer/scheduled-payments/{scheduled_payment_id}/cancel needs that id. Integrate the two together: list, then cancel by the id an item carries. Each item carries maximumAmountSnapshot — the ceiling in force when the debit was SCHEDULED, written once and never updated — so a payer who has since changed the ceiling can see why an existing debit still reflects the old one. Returning it here is the payer's own authenticated channel; Guia v1.2 §6.1 bars sharing it with the RECEIVING user and their PSP, which this surface is not. Ordering is by scheduledDate and then by id, which is also what the cursor resumes on — not the write instant, unlike the three sibling listings. authorizationId is absent on a debit scheduled without a mandate (purpose RIFL), and maximumAmountSnapshot is absent when no ceiling was in force; neither absence is an error. Paging is by cursor. On the last page next_cursor is null, never an empty string. operationId: listPayerScheduledPayments 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: >- Maximum number of records per page (1-100, default 10). A value outside that range, or one that is not an integer, is REFUSED — never clamped, never silently coerced. example: 25 explode: false in: query name: limit schema: default: 10 format: int64 maximum: 100 minimum: 1 type: integer - description: >- Opaque cursor taken from a previous page's next_cursor. On the last page that value is null, never an empty string. A malformed or undecodable value is refused with 400. The cursor must be replayed against the same endpoint, with the same sort_order and the same filters used to obtain it; changing any of those starts a different query, and the previous cursor should not be reused. explode: false in: query name: cursor schema: description: >- Opaque cursor taken from a previous page's next_cursor. On the last page that value is null, never an empty string. A malformed or undecodable value is refused with 400. The cursor must be replayed against the same endpoint, with the same sort_order and the same filters used to obtain it; changing any of those starts a different query, and the previous cursor should not be reused. examples: - >- eyJ0IjoiMjAyNi0wOC0yN1QxODo0MjowMFoiLCJpIjoiMDE5OGYzYTEtN2M0Mi03ZGUxLWEwMjQtYjFmMGI3ZTljMzAxIn0= type: string - description: >- Sort direction. An unrecognised value is refused rather than silently defaulted, because switching it mid-traversal without notice would silently reverse the page sequence the caller is walking. explode: false in: query name: sort_order schema: default: desc description: >- Sort direction. An unrecognised value is refused rather than silently defaulted, because switching it mid-traversal without notice would silently reverse the page sequence the caller is walking. enum: - asc - desc examples: - desc type: string responses: '200': content: application/json: example: items: - amount: '149.90' createdAt: '2026-09-01T12:00:00Z' id: 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40 purpose: AGND recurrenceId: RN12345678202608101a2b3c4d5e6 scheduledDate: '2026-09-10' status: SCHEDULED updatedAt: '2026-09-01T12:00:00Z' next_cursor: >- eyJ0IjoiMjAyNi0wOS0xMCIsImkiOiIwMTk4ZjNhMi0xYzRlLTdjOGItOWQxZS0yZjNhNGI1YzZkNDAifQ== prev_cursor: null schema: $ref: '#/components/schemas/ScheduledPaymentPage' description: >- A page of scheduled debits, newest settlement date first. Empty when the account named in X-Account-Id has none. '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). '401': content: application/json: example: code: PIX-0004 message: Invalid or expired authentication credentials. title: Unauthorized schema: $ref: '#/components/schemas/Error' description: The caller is not authenticated (PIX-0004). '403': content: application/json: example: code: PIX-0005 message: You do not have permission to perform this operation. title: Forbidden schema: $ref: '#/components/schemas/Error' description: >- The caller is authenticated but not entitled to this resource (PIX-0005). '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. components: schemas: ScheduledPaymentPage: additionalProperties: false properties: items: description: >- Empty array when there are no results — never null. An empty array means the account named in X-Account-Id has no scheduled debit. items: $ref: '#/components/schemas/ScheduledPaymentItem' type: array next_cursor: description: >- Opaque cursor for the next page. NULL on the last page, never an empty string. examples: - >- eyJ0IjoiMjAyNi0wOC0yN1QxODo0MjowMFoiLCJpIjoiMDE5OGYzYTEtN2M0Mi03ZGUxLWEwMjQtYjFmMGI3ZTljMzAxIn0= type: - string - 'null' prev_cursor: description: >- Opaque cursor for the previous page. These listings do not issue a backwards cursor, so the value is null. type: - string - 'null' required: - items - next_cursor - prev_cursor 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 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, which a same-day resend (purpose RIFL) legitimately may. 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 POST /v1/payer/scheduled-payments/{scheduled_payment_id}/cancel — this listing is the only published operation that returns it. 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. 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. enum: - SCHEDULED - DISPATCHING - SETTLED - FAILED - CANCELLED - RECONCILING type: string updatedAt: format: date-time type: string required: - id - recurrenceId - amount - scheduledDate - purpose - status - createdAt - updatedAt type: object RawError: additionalProperties: false properties: message: examples: - upstream provider returned 503 type: string status: format: int64 type: integer required: - status - 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.90' 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 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.