Cards
Debit, credit and prepaid cards, with their movements.
Each card carries its type, its masked number, the account it settles against, the limits and balances the institution publishes, and the transactions retrieved. Field by field in Cards.
A debit card usually has no movements of its own. It spends the balance of the account it is bound to, so its purchases are that account’s transactions; a credit card is the one with a statement of its own. Read both together, and expect transactions to be empty on the debit side.
Card numbers are never reconstructed. What comes back is what the institution itself shows — a masked number — handled as protected data end to end.
Requires the cards_read feature
Features are chosen when the execution starts, not here. An execution that did not ask for cards_read answers 204, and the only way to get the data is to run another one.
Movements are opt-in: read_transactions defaults to false, so a run that did not ask for it returns the cards without them. from_date / to_date decide the period, and filter_by_type narrows which kinds are read.
Server to server only. This call is authorised with your application secret: it belongs in your backend, never in a browser, a mobile app or anything your customer can read.
Authentication
Path parameters
Response
200 OK
Credit, debit and prepaid cards in one list. product and sub_family say which kind each one is, and the fields that only exist for one of them are absent from the others rather than empty.
An empty list is an answer, not a gap: the feature ran and the source reported none.