> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iron.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Note>
  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](/versioning) for the header itself.
</Note>

## 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](/onboarding).

<Warning>
  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.
</Warning>

<Note>
  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.
</Note>

## 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.

<Warning>
  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.
</Warning>

## 2025-03-13

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