# Balance, statement and limits (/en/docs/conta-digital/statement) The four routes use the `STATEMENT_READ` scope. ## Balance [#balance] [`GET /transactions/balance`](/docs/conta-digital/endpoints/account/get_balance) ```json { "total": 152030, "available": 150530, "blocked": 1500, "blockedBySecurity": 1500, "blockedByWithdraw": 0, "blockedByRefund": 0, "syncedAt": "2026-10-06T18:20:11.004Z" } ``` | Field | Description | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `available` | The available balance: what can be used now for withdrawals, Pix copy-and-paste payments and refunds. It is the sum of the statement lines. | | `blocked` | It is in the account but cannot be used, such as the amount of an open MED dispute or of a withdrawal, refund or transfer still being processed. `blockedBySecurity`, `blockedByWithdraw` and `blockedByRefund` split this amount by reason. | `total` is `available + blocked`. All fields in [Get balance](/docs/conta-digital/endpoints/account/get_balance). The withdrawal amount plus the fee (`withdraw` in [limits](#limits)) must fit in `available`. Even so, the withdrawal can be refused with `WITHDRAW_INSUFFICIENT_PROVIDER_BALANCE`: the bank does not cover the withdrawal at that moment. ## Statement [#statement] [`GET /transactions/statement`](/docs/conta-digital/endpoints/account/get_statement)?limit=20\&dateFrom=2026-10-01\&trigger=PAYOUT Each line is an entry that changed the available balance, not a whole operation. A paid R$ 15.00 charge with a R$ 1.05 fee comes in as `+1395`. A withdrawal goes out at the time of the request, with the amount and the fee together (`amount + serviceFee`). ```json { "data": [ { "id": "cmu9r1a2b000101s6stmt0002", "entryId": "cmu9r0z9y000001s6entr0002", "amount": -10250, "balanceAfter": 150530, "trigger": "PAYOUT", "description": "Reserva de saque", "originId": "cmu3wd7k1000201s6wdrw0001", "infractionProtocol": null, "gross": 10000, "fee": 250, "status": "SETTLED", "statusDetail": null, "statusReason": null, "statusAt": "2026-10-05T14:40:14.120Z", "payoutOperation": "WITHDRAW", "counterparty": { "name": null, "document": null, "pixKey": "f***@exemplo.com" }, "postedAt": "2026-10-05T14:40:11.002Z" } ], "nextCursor": "cmu9r1a2b000101s6stmt0002", "balance": 150530 } ``` | `trigger` | The line | | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | | `PAYMENT` | Paid charge, already without the fee. | | `DEPOSIT` | Pix received without a charge, already without the fee. | | `PAYMENT_REFUND` | Refund: the amount going out, or coming back when the refund is refused. Also the refund the bank makes on its own. | | `PAYOUT` | Withdrawal or Pix copy-and-paste payment going out, at the time of the request. | | `PAYOUT_REVERSAL` | The withdrawal amount coming back, when it failed. | | `PAYOUT_REFUND_RECEIVED` | Return of a Pix sent by the account. | | `INFRACTION_BLOCK` | MED dispute opened: the amount leaves the available balance. | | `INFRACTION_SETTLED` | Dispute upheld: the amount went back to the payer. | | `INFRACTION_RELEASED` | Dispute rejected: the amount comes back, minus the analysis fee. If the dispute was cancelled, it comes back in full. | | `INTERNAL_TRANSFER` | Transfer between accounts, on both sides. The sign of `amount` says the side. | * `status` is the current state of the operation, for withdrawals, refunds and transfers: `PROCESSING` (still being processed), `SETTLED` (completed) or `RETURNED` (refused, with the amount back). On the other lines, it comes `null`. `description` does not change once written: the outflow of a completed withdrawal still reads "Reserva de saque". * `statusDetail` comes in two cases. `APPROVAL_REFUSED`: the bank did not approve the withdrawal, the amount stays out of the available balance and `statusReason` carries a message for display. `PROVIDER_REFUND`: the bank returned the money to the payer without a request from you. * `counterparty` is the other party in the operation. On inflows, who paid: on a charge, the customer you provided, with the full document; on a Pix without a charge, with the document masked. On outflows, `pixKey` carries the masked destination key. On dispute lines, it comes `null`. * `balance`, next to `data`, is the available balance now. ### Filters [#filters] | Filter | Description | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `originId` | The operation id as it comes in the webhooks: `paymentId`, `withdrawId`, `depositId` or `transferId`. The `id` returned when creating the charge, the withdrawal or the transfer does not work here. | | `trigger` | One or more line types, separated by commas. | | `dateFrom`, `dateTo` | A date without a time covers the whole day in Brasília time. | | `status` | State of the source operation. See below. | Filters apply together. A parameter the route does not know is refused with `400` and `REQUEST_UNKNOWN_QUERY_PARAM`. All filters in [Get statement](/docs/conta-digital/endpoints/account/get_statement). The `status` filter looks at the state of the operation that generated the line, not at the line's `status` field. It brings all lines of the operations in that state, including refund lines. Transfer and dispute lines are left out. ## Limits [#limits] [`GET /transactions/limits`](/docs/conta-digital/endpoints/account/get_limits) returns the limits and fees that apply to the account now. Amounts in cents; `feePercentage` is a percentage (`150` = 1.5%). ```json { "payment": { "enabled": true, "ticketMin": 100, "ticketMax": 1000000, "feeFixed": 105, "feePercentage": 0 }, "withdraw": { "enabled": true, "ticketMin": 100, "ticketMax": 1000000, "feeFixed": 100, "feePercentage": 150 }, "externalPayment": { "enabled": true, "ticketMin": 100, "ticketMax": 1000000, "feeFixed": 100, "feePercentage": 0 }, "refund": { "enabled": true, "ticketMin": 100, "ticketMax": 1000000, "feeFixed": 100, "feePercentage": 0 }, "internalTransfer": { "enabled": true, "ticketMin": 100, "ticketMax": 1000000, "feeFixed": 100, "feePercentage": 0 }, "dailyWithdraw": { "limit": 1000000, "used": 12850 }, "dailyInternalTransfer": { "limit": null, "used": 0 }, "infraction": { "feeFixed": 500, "feePercentage": 0, "blocksBalance": true } } ``` | Block | Describes | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `payment` | Charge. | | `withdraw` | Withdrawal to a key. The minimum and the maximum apply to every Pix outflow. | | `externalPayment` | Pix copy-and-paste payment: the withdrawal limits, with its own fee. | | `refund` | Refund and deposit return, with its own fee. The maximum per operation is the withdrawal one; the minimum is not applied. | | `internalTransfer` | Transfer between accounts. | | `dailyWithdraw` | Daily cap on Pix outflows and how much was already used today. | | `dailyInternalTransfer` | The same, for transfers between accounts. | | `infraction` | Analysis fee charged when the MED dispute is rejected, and whether the disputed amount leaves the available balance while the analysis runs (`blocksBalance`). | For each operation, `enabled` says whether it is allowed, `ticketMin` and `ticketMax` are the smallest and the largest amount, and the fee adds a fixed part (`feeFixed`) and a percentage part (`feePercentage`). In the daily caps, `limit: null` means no cap and `0` blocks everything. With a cap, `used` counts the day in Brasília time, including operations still being processed; without a cap, it comes `0`. ## Metrics [#metrics] `GET /transactions/metrics?dateFrom=2026-09-01&dateTo=2026-09-30` Without `dateFrom` and `dateTo`, the period is the last 30 days. * Charges count by creation date: September's conversion is the share of charges created in September that was paid, even if the payment came in October. * `rails` carries one item per payment method of the account. A method without metrics comes with `available: false` and no numbers; Pix with no charges in the period comes with the numbers at zero. * The rates (`conversionRate`, `refundRate`, `disputeRate`) follow the `feePercentage` format and come `null` when there is no base. * `withdrawals` adds up the withdrawals that did not fail, with the fee. `deposits` adds up the Pix received without a charge. `pixInflow` adds up paid charges and deposits. All fields are in [Get metrics](/docs/conta-digital/endpoints/account/get_metrics).