Skip to content
ZTLDeveloper Portal

Capabilities and constraints

Treat discovery responses as configuration, not as background information to copy into code. Availability can differ by environment, partner, bank, branch, country, and product.

Supported banks and products

Section titled “Supported banks and products”

Call GET /api/v2/banks/{countryCode}/supported before presenting a bank or starting consent. For the selected bank:

  • verify the required product in supportedProducts;
  • present a branch choice when branches is returned, then send the chosen bankBranch when creating consent;
  • apply the bank or branch constraints, including field lengths, character patterns, basket or bulk limits, entry date ranges, and cancellation SCA; and
  • treat branch constraints as authoritative when they differ from bank-level constraints.

Do not infer support from the BIC alone or assume every bank in a country supports consent, accounts, domestic payments, international payments, payroll, and bulk payments.

Countries, currencies, and regulatory codes

Section titled “Countries, currencies, and regulatory codes”

Use these operations when constructing a cross-border or FX form:

Need Runtime operation
Supported destination countries GET /api/country
Account formats and required recipient fields GET /api/country/{country}/paymentrequirement
Supported currencies GET /api/currencies
Regulatory reporting choices GET /api/v2/payments/regulatory-reporting/codes/{countryCode}

A listed country or currency does not guarantee that every route is enabled for the partner. Build required fields from the country response, validate them before creation, and tolerate newly added enum values.

Company capabilities

Section titled “Company capabilities”

Use GET /api/companies/supported/{countryCode} to discover supported company types. Some operations, such as AIS-only registration, international-payment enablement, and subscription changes, require a prior agreement or partner configuration. An operation appearing in the API reference does not by itself grant access.

Confirm product enablement with ZTL before production rollout. Keep runtime responses authoritative after launch so capability changes do not require an application release.