Changelog

What changed in each API version, newest first. See API Versions for how X-API-Version negotiation works.

Each dated version is a frozen contract: once cut, its response and request shapes never change under you. This page lists what changed relative to the version before it. Entries are newest first.

This is the human-readable version. GET /spec/versions lists the supported versions machine-readably, and each version’s full shape is at /spec/<date>. See API Versions for the header itself.

2026-08-01

Customers sign the terms and conditions before identification.

Affects	Behaviour — no request or response shape changes
Kind	Changed (onboarding order), pinned per customer
Endpoints	POST /customers, GET /customers/{id}/required-signings

A customer created on this version starts in SigningsRequired instead of IdentificationRequired: the terms carry the data-sharing agreement, so acceptance now comes before Iron collects KYC data. After approval Iron compares the signed terms against the verified region and returns the customer to SigningsRequired to re-sign if they differ.

GET /customers/{id}/required-signings also changes: when nothing is outstanding it returns 200 with an empty list, where earlier versions return 409 Conflict.

Because the lifecycle plays out in webhooks and background work with no request header to read, this version is pinned to the customer when you create it and drives that customer’s onboarding for its lifetime. Customers created earlier keep the original order whatever header you send later, so adopting it only affects customers created from then on. See Onboarding.

An empty list from required-signings does not always mean “nothing to sign”. Before identification is approved there is no verified region to derive terms from, so a customer in SigningsRequired also returns 200 []. Treat that as “ask the customer for their country” and fetch the terms with GET /terms-and-conditions?country={ISO3}; only an empty list on an Active customer means nothing is outstanding.

This version cannot be verified from the OpenAPI document alone — the shapes are identical to 2026-07-01. Rehearse the status sequence in sandbox, which reproduces the pre-identification flow including the empty required-signings response.

2026-07-01

Adds the FedNow deposit rail.

Affects	Response
Kind	Added (union variant)
Endpoints	Any response containing an Autoramp object: POST /autoramps, GET /autoramps, GET /autoramps/{autoramp_id}, PATCH /autoramps/{autoramp_id}, GET /autoramps/{external_id}/external, POST /autoramps/{autoramp_id}/quotes

The deposit_rails array can now include a FedNow member, for autoramps whose deposit account supports FedNow. This is additive to the DepositRail union: every existing member (Iban, AchWire, Swift, and the rest) is unchanged.

If your integration matches on deposit_rails with an exhaustive switch and no default case, add a FedNow branch before sending X-API-Version: 2026-07-01. Callers on 2025-03-13 never see this variant, so there is no rush to migrate.

2025-03-13

Initial version. Served when no X-API-Version header is sent.