API versioning & compatibility

BankConnector's HTTP API is versioned by date, via the BankConnector-Version header, never a /v1 path prefix. Pin a version and the contract stays stable for you as the platform evolves underneath it.

BankConnector-Version: 2026-06-01

Every response echoes back the version it was served under (including error responses), so you can confirm what you're pinned to at a glance. Omit the header and you get the current version's behaviour.

Compatibility commitment

We treat the API as a long-lived contract:

• A pinned version keeps behaving the way it did when you integrated it. We do not make breaking changes to a version you've pinned.
• Additive changes (new optional request fields, new response fields, new endpoints) may appear within a version without notice. Build tolerant clients (ignore unknown fields, branch on code not message) so these never break you.
• Breaking changes ship under a new dated version. The previous version keeps working, and you move on your own schedule after advance notice; you're never forced to migrate on our timeline.

This is why we recommend pinning BankConnector-Version explicitly in production rather than relying on the default.

Current version: 2026-06-01

• Canonical input schema 1.1 (additive over 1.0: structured postalAddress, regulatoryReporting, and purposeCode / localInstrument / categoryPurpose overrides; see Core Concepts).
• Object error envelope: { error: { code, message, details? } } on every non-2xx response (see Errors & Retries).
• Standard list envelope: { items, nextCursor?, total? } across all list endpoints (see Pagination).

Contract changes

Integrator-facing contract changes (new fields, behaviour changes, deprecations) are recorded here as the API evolves, each under the dated version that introduced it. Internal work (refactors, security hardening, infrastructure) never appears here, because it doesn't change what you integrate against. If you pin a specific BankConnector-Version, watch this page.