Endpoint responsible for retrieving charges registered in the account in a paginated way, with support for filters by customer, payment method, status, dates, and operational links.

Unlike retrieving a specific charge, this request returns a list of records that match the parameters provided in the query.

How listing works

The response from this endpoint is paginated.

This means that charges are returned in blocks, according to the navigation parameters sent in the request. This behavior is important for integrations that handle large volumes of data, reconciliation routines, or administrative interfaces.

Main request parameters

Some filters are more commonly used in integration flows:

• customer — Filters charges for a specific customer
• customerGroupName — Filters charges by the customer's group name
• billingType — Filters by payment method
• status — Filters by the current charge status
• subscription — Filters charges linked to a subscription
• installment — Filters charges linked to an installment plan
• externalReference — Filters by the identifier used in the source system
• invoiceStatus — Filters charges according to the status of the linked invoice
• anticipated — Filters records that have already been anticipated
• anticipable — Filters records eligible for anticipation
• dateCreated[ge] and dateCreated[le] — Filter by creation date range
• dueDate[ge] and dueDate[le] — Filter by due date range
• paymentDate[ge] and paymentDate[le] — Filter by payment date range
• estimatedCreditDate[ge] and estimatedCreditDate[le] — Filter by estimated credit date range
• user — Filters by the email of the user who created the charge
• checkoutSession — Filters by the checkout session identifier

Most common use cases

This endpoint is commonly used to:

• locate a customer's charges
• retrieve charges by status
• list charges by payment method
• support reconciliation routines
• retrieve charges linked to subscriptions or installment plans
• populate administrative screens with operational filters

🚧

Attention

This endpoint should not be used for continuous status polling.

Polling is the practice of making repeated GET requests to check for charge status changes. In addition to being a poor integration practice, this behavior increases resource consumption and may lead to the API key being blocked for abuse.

To track status changes, the recommended approach is to use Webhooks.