FAQ

Client credentials. The token endpoint accepts the fields for several grants in one request shape — which fields you send is what selects the flow — and for a bank integrating server to server it is the one that applies. The portal's own request builder uses it.

Authentication has the full table.

Correct — no published document declares a security scheme, so none of them states it. It goes in an Authorization: Bearer <token> header on every operation except the token service's own five.

Read expires_in from the token response and honour it; cache the token until then rather than fetching one per call, and refresh slightly early so a call does not fail on a token that expired in flight. Do not code a fixed lifetime — what this installation configures is not published, and it is listed as an open question on the authentication page.

No. Each published document declares exactly one server and it is the sandbox, so the request builder and the downloadable files all point there. Production addresses are not published here — see Environments.

Because every published operation is. All 356 of them use POST and carry their input in a JSON body — getCardList included. There is nothing in the query string and nothing in the path but the operation's name.

The specifications do not say, and the `required` array in them is not an answer. It is a Swashbuckle marker for non-nullable C# value types and is perfectly anti-correlated with nullable; reading it as a contract will have you sending fields that are optional and omitting ones that are not.

Where this portal states that a field is required, a person established it from the service. Where nothing is stated, the operation's own validation is the authority — and it answers with a 400 naming the field in propertyName.

No — not on the 187 operations that take it. The platform authorises against the channel, several operations behave differently per channel, and status transitions are permitted per channel group rather than globally. 18 codes are published in Channels; decide yours before you write the client.

shadowCardNumber is the platform's reference to the card and is what most operations are keyed by (169 of them). cardRefNumber names the card record (34). cardNumber is the real PAN and appears on a small, named set of operations only.

They are not interchangeable where an operation takes more than one. Store and log the shadow number; it is the one that is safe to keep.

Not necessarily. The operations that return a card's whole picture assemble it from several services — issuing, lifecycle, limits, PIN and the customer service. An absent field can mean the card has no such value or that one of those services did not answer, and the response does not distinguish them.

Where a decision hangs on the value, read it from the operation that owns it rather than from the summary.

Not the API you called. The money operations on the digital channel APIs are facades: they carry your request to the authorisation service or to transaction management and carry the answer back, with little or no business rule of their own.

It matters when something fails. A refusal usually originated behind the operation you called, so the code and the wording belong to that service — and the first question in a support thread is which one.

Content-Type: application/json, and that is all that is required. evrst-ptrnid is a correlation id you choose; the portal's generated code samples set it because a call you can find again in a log is worth one line, but the platform does not require it.

errorCode, and nothing else. message carries substituted values and is written for a person; messageFormat is the stable string if you need to group errors in a log. Log transactionId on every failure — it is what support traces the call by.

On an operation that takes a list, 200 means the call ran, not that every row applied: each row resolves independently and its outcome is in the response body. setCardOperationLimit is the one that catches people. Read the result list rather than the status code.

Almost always the operation is on a different API. Operation names repeat across the published set — 101 of the operation records share a name with another — so changeCardStatus exists in more than one place and a path is only valid on the API that owns it.

The API reference shows the operation under its own API, and Developer tools has a .http file per API with the right base address already in it.

Report it. The specifications declare the 400 envelope but not a single code value, so the catalogue is the whole of what is published — a code outside it is a gap in the catalogue rather than something for you to infer a meaning for.

They were read out of the services, because the specifications carry none. And the governing column is usually not the one the value is stored in — it is the definition table the value is checked against, or the table it must match a row in.

A code can fit the storage column and still be impossible to define, so the bound you actually meet is the narrower one. That is the number the reference publishes.

Because one name covers three different columns, and which applies depends on what the operation reads: the delivery integration record (13), the no-name card stock (120) and the card application (20).

The reference publishes the width that applies to the operation you are looking at. Carrying one value between them is how a request that worked on one call is refused on the next.

Four is what you should send and what the field is named for. It is not what the code enforces: there is no length check, and the value is matched against the end of the masked card number. So the technical bound is that column's width, and anything longer can never match.

It is the clearest case of the general rule above — the name of a field and the limit the service applies are two different facts.

The reference. The width published is the one a caller actually meets, and it is usually the definition table the value is checked against rather than the column it ends up in.

logCode is the clearest case: the log row stores twenty characters, but every read of a card log joins the log definition table and the operations that write one refuse a code it does not hold — and that table allows ten. A longer code can be neither defined nor matched, so ten is the bound. restrictionCode is the same shape: four fits the storage column on credit and three is all the definition table will ever hold.

No. The generated list mappers start with an empty list and return it whether or not the reader had rows, so no records is an empty list and never a null.

Which is why the platform's own validation speaks of a list having no items rather than of a list being absent, and why a null check on a read result is in practice a count check.

No. Nullability in these documents is a C# artefact of how they were generated, not a statement about the contract. Whether a value may be absent is the operation's own validation, and this portal states it only where a person established it.

Because it genuinely is different. Six representations are published — --, an empty string, ---, N, O and 0 — and each comes from the definition that field is bound to rather than from a choice this portal made. Normalising them here would tell you to send a value the platform does not accept.

Then it was published and nothing in the platform read it. Two were removed in October 2026 after being traced through the services: a card option value no code writes or compares, and a delivery type that parses and is then compared against by nothing — a card written with it is neither posted nor collected at a branch.

Both were removed rather than explained, because documenting a value makes banks send it. If a removal breaks a call you are making today, that is worth reporting — it would mean the trace missed a reader.

That the platform does not expose it here today, and the portal says so rather than leaving a silence. It is a scoping fact, not a roadmap date: the capability's own page carries what is missing. See the capability map.

They moved rather than ceased. Thirty-one published operations came off the core banking indoor API when the digital channel integrations took over that work, and most now live under a shorter name on the API that owns them — changeDebitCardStatus is changeCardStatus on debit, setCreditCardPin is setCardPin on credit.

The changelog records the move.

Prepaid has no allocated limit at all: what can be spent is a loaded balance. A card refers to a wallet through its shadow card number, and one wallet can hold more than one balance — by currency or by purpose. So the credit vocabulary of increase, decrease and reset has no counterpart; the prepaid verb is load.

None of that is exposed as an operation on this portal. Loading funds, card-to-card transfer and reading a wallet balance have no published endpoint, which is stated as a gap on the journeys rather than left for you to discover. Issuing, status, PIN and embossing all work for prepaid exactly as they do elsewhere — the money side is the part that is missing.

Developer tools has, per API, the OpenAPI document, a Postman collection and a .http file your editor can run — every operation, generated from the same compiled model this site renders from, so they cannot describe a call the platform no longer has. 6 APIs are published.

Yes. Every page has a markdown twin at its own /md path, and there is a hosted MCP server that serves the same compiled model with search over it. Agent access has the address and the tools.