List Financial Movements

This article describes how to retrieve a consolidated, paginated history of every money operation associated with your account through a single endpoint. Unlike GET /mint_platform/v1/transactions, which scopes the result to stablecoin transactions, financial movements aggregate entries from multiple backend sources — fiat and crypto deposits, fiat and crypto withdrawals, and BRFQ conversions — into one consistent representation.

The GET /mint_platform/v1/financial_movements method returns a page of financial movements for the authenticated user, sorted by creation date descending. Movements are exposed as a unified resource: the underlying data sources are an implementation detail of the API, not part of the public contract.

For the full request and response contract — query parameters, schemas, examples, and error codes — see the API reference: List financial movements.

This endpoint requires the "View account information" permission enabled in your API key.

Movement Categories

Every movement carries a type field that signals which detail object is populated. Exactly one of funding, withdrawal, or conversion will be present per movement.

Movement Statuses

Each movement has a canonical lifecycle status, normalized from the upstream provider's raw status:

• PENDING: Accepted but not yet picked up for processing.
• PROCESSING: In flight — funds are moving, or a conversion is being executed.
• COMPLETED: Terminal success.
• FAILED: Terminal non-success (for example, insufficient funds, cancelled, rejected). When a movement reaches FAILED, the response also includes an inline error object on the resource (following the asynchronous-error pattern), with code and message.

Pagination

This endpoint uses token-based pagination, not page numbers. To traverse the full collection:

1. Issue the first call with no page_token (or omit the parameter entirely).
2. Read the next_page_token field from the response.
3. Call the endpoint again, passing that value as page_token. Repeat.
4. When the response no longer includes a next_page_token (the field is absent or null), you have reached the end of the collection.

Page tokens are opaque — do not parse, modify, or persist their contents; pass them back as-is. The default and maximum page_size is 20; values above the maximum are clamped server-side.

Because each page is anchored by an opaque token, there are no page numbers and no global total_elements count. The total_count field reflects the number of movements in the current page only.

Response Notes

A successful call returns the page payload directly — there is no success/payload envelope wrapping the body. This differs from most other /mint_platform/v1 endpoints.

A few details on the per-movement payload that are worth highlighting:

• id (movement identifier): An opaque string scoped to the movement's category. It carries the upstream-emitted UID of the originating deposit, withdrawal, or BRFQ quote, so the format is not guaranteed to be a UUID: conversions surface the BRFQ quote_uuid (a UUID), but fundings and withdrawals may surface a UUID, a hex string (e.g. derived from a blockchain transaction hash), or another rail-specific identifier. Treat it as opaque — don't parse it or assume a fixed shape.

• Rail discriminator and rail-specific fields: On both funding and withdrawal, the inner type field tells you which rail the leg used — one of SPEI, BITSO_TRANSFER, or CRYPTO. The matching nested object on the leg is populated to carry the rail-specific fields: spei for SPEI, bitso_transfer for internal-transfer, or crypto for on-chain. Common fields (asset, amount/gross_amount/fee/net_amount, origin_*) stay at the top of the leg; the rail-specific identifiers and references live inside the nested object.

• spei: Carries the SPEI participants and the SPEI tracking key (clave de rastreo). On funding: source_clabe (sender), destination_clabe (user-side receiver), and external_id. On withdrawal: only destination_clabe (external receiver) and external_id — the Bitso-side originating CLABE is intentionally not exposed for fiat withdrawals.

• crypto: Carries the on-chain participants and the blockchain transaction hash. Fields: network (e.g. ETHEREUM, ARBITRUM, POLYGON), source_address, destination_address, and transaction_hash. On withdrawal, source_address (the Bitso-side hot wallet) and transaction_hash may be absent until the rail confirms.

• bitso_transfer (internal-transfer rail used by issuance/redemption flows): Only the upstream-emitted reference (external_id) is surfaced — internal Bitso source/destination accounts are intentionally hidden because they reference accounts not exposed through the public API.

• Platform-originated movements: When a movement stems from another platform action (for example, a redemption that was refunded back to the user, or an issuance that was refunded), the leg includes juno_transaction_type, juno_transaction_id, and refund. juno_transaction_type is the category of the originating Juno transaction (e.g. REDEMPTION, ISSUANCE), and juno_transaction_id is its identifier, which clients can correlate against /mint_platform/v1/transactions/{transactionId}. These fields are absent for organic movements.

• Decimal amounts: Returned as JSON strings (for example, "1000.00") to preserve precision, in line with the rest of the /mint_platform/v1 surface.

• Timestamps: created_at and updated_at are ISO-8601, UTC, with millisecond precision (pattern yyyy-MM-dd'T'HH:mm:ss.SSSXXX, e.g. "2026-01-15T10:30:00.000Z"). The precision is uniform across every movement on the response — sub-second fractions are always present, even when they are zero.