Skip to main content
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. A customer created on this version starts in SigningsRequired instead of IdentificationRequired: the terms carry the data-sharing agreement, so acceptance now comes before MoonPay Enterprise collects KYC data. 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.
On its initial release, an empty list from required-signings did not always mean “nothing to sign”: before identification was approved there was no verified region to derive terms from, so a customer in SigningsRequired also returned 200 [], and you had to fetch the terms with GET /terms-and-conditions?country={ISO3} instead. The update below removed that ambiguity — required-signings now returns the outstanding document at any point in the lifecycle, including before identification.
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.
Update: a single global document now applies regardless of country, replacing per-region terms. Since this version’s initial release, the terms and conditions document required-signings and terms-and-conditions?country= return has changed: MoonPay Enterprise now serves one global document to every customer created on this version, rather than a document specific to their country’s region. Response shapes are unchanged — you still get a list of {id, url, display_name} — and country is still a required parameter on GET /terms-and-conditions?country={ISO3} for backward compatibility, but its value no longer affects which document comes back. The region-mismatch re-sign case this section originally described (validating the signed terms against the verified identification’s region, and asking for a re-sign on a mismatch) no longer applies to customers created on this version: there is only one document to sign, so nothing to mismatch against. GET /customers/{id}/required-signings also covers the whole lifecycle for these customers, returning the outstanding document before identification as well as after — so a single code path replaces the earlier split between terms-and-conditions?country= and required-signings. country is still accepted for backward compatibility. Note that re-signing does not disappear entirely: publishing a new document still returns affected customers to SigningsRequired. See Signing new terms later.
If your integration already recorded a signing for a customer created on this version before this update, that signing may not satisfy the new global-document requirement. Check GET /customers/{id}/required-signings for any customer created between this version’s initial release and this update — a non-empty response means they need to sign the (single) current document.
Identification failures return structured, machine-readable errors. A failed Business, Person, or Token identification submission now returns 400 with an array of {code, message, docs_url, beneficiary_index} objects instead of a plain error string, so your integration can branch on code instead of pattern-matching English text. See Identification Errors for the full list of codes. Most checks return a single entry, but the four document-requirement codes (company_details_required, legal_presence_required, ownership_structure_required, control_structure_required) can each appear once per company in the submission that’s missing that group — a non-US Business submission checks all four independently, so several can genuinely be missing at once.
Callers on an earlier or unversioned X-API-Version keep receiving today’s plain error string on 400, unchanged.

​
2026-07-01

Adds the FedNow deposit rail. 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.