Moov's API versioning follows the format `vYYYY.QQ.BB`, where - `YYYY` is the year - `QQ` is the two-digit month for the first month of the quarter (e.g., `01`, `04`, `07`, `10`) - `BB` is the build number, starting at `.00`, for subsequent builds in the same quarter. For example, `v2026.01.00` is the initial release of the first quarter of 2026. ## Lifecycle Each quarter's API version is released at the start of that quarter. For example, `v2026.07.00` will be released in July 2026. Once released, a version is considered stable and will only receive non-breaking changes. When a new version is released, work begins on the next quarter's version, which is considered in development. The in development version receives new features, breaking changes, and non-breaking changes throughout the quarter. For example, once `v2026.07.00` is officially released in July, `v2026.10.00` enters _in development_ and will eventually be available for early access. Note - if no changes are made to the _in development_ API version, that version will be skipped for an official release and will disappear from our public documentation. If no API version is passed in your header request, Moov will default to `v2024.01.00`. ## Available versions - `v2026.07.00` (current) - `v2026.04.00` - `v2026.01.00` - `v2025.07.00` - `v2025.04.00` - `v2025.01.00` - `v2024.01.00` (default) The _in development_ version of the API always represents the next quarter's API. ## Setting the API version To use a specific API version, set the `X-Moov-Version` header on every request: Ask ```fallback X-Moov-Version: v2026.04.00 ``` ## 2026.07.00 - Adds support for deferred payments, from 24-48 hours, in payment links and push-to-card transfers - Adds the `/card-metadata` [endpoint](https://docs.moov.io/api/sources/cards/metadata/) which allows you to to look up metadata for a card without linking it to a Moov account. This endpoint requires you to provide Moov with a copy of your PCI attestation of compliance before use. - Removes `salesTaxAmount` on payment links and transfers - Adds `amountDetail.tax` to payment links and transfers - Adds support for surcharge fees for credit card transactions in `amountDetails.surcharge` in payment links and transfers - Adds support for tipping in `amountDetails.tip` in transfers and with the `/accounts/{accountID}/transfer-config` endpoint for payment links ## 2026.04.00 - Adds [resolution links](https://docs.moov.io/api/moov-accounts/resolution-links/). Resolution links are temporary, secure links sent to accounts to resolve requirements such as KYC verification or document uploads. - Adds [invoices](https://docs.moov.io/api/money-movement/invoices/). Accounts can generate an invoice with line items to send to customers. - `instantBankDetails` replaces `rtpDetails` in the transfer response. In the future, `instantBankDetails` will also show FedNow details. ## 2026.01.00 Adds the `instant-bank-credit` payment method for real-time payments via RTP (FedNow support coming soon). While `rtp-credit` will continue to be supported, Moov strongly suggests moving to the `instant-bank-credit` payment method. ## 2025.07.00 - New support tickets allow you to hand off connected account support to Moov, and Moov will respond - Granular capabilities allow you to only request the capabilities you need, shortening onboarding time - Underwriting dynamically generates based on an account's business profile and requested capabilities - New enriched industry taxonomies model - Allows Moov to create guest accounts for Tap to Pay processing ## 2025.04.00 - Adds support for a `terminalCard` source and the `card-present-payment` payment method type for in-person payments. ## 2025.01.00 - Updates error response status codes. ## Breaking changes - Non-breaking changes may be added to a release even after it becomes stable. - Minor breaking changes may be added to a release while it's in beta. Moov attempts to minimize this as much as possible. - Brand new features or major breaking changes will be in the _in development_ branch, which is typically the next future quarter's API. Moov may release new features or major breaking changes for customers who are in specific beta programs or testing various features with us. See the [breaking changes](https://docs.moov.io/guides/developer-tools/breaking-changes-api/) guide for more details. ## Moov SDKs Moov's official SDKs set the `X-Moov-Version` header automatically. Each SDK release is pinned to a specific API version — you don't need to set the header yourself. ### SDK versioning SDKs are generated from each API version. SDK versioning will have the following format: | API version | SDK version | | --- | --- | | `v2026.07.00` | `26.4.x` | | `v2026.07.00` | `26.7.0-dev.x` | The table above uses `v2026.07.00` as an example of an _in development_ API version. The corresponding `-dev.x` SDK version indicates an _in development_ version of the SDK and should be used with caution. The _in-development_ API version will typically always be the next quarter's release. Currently, Moov supports the following SDK versions for TypeScript, PHP, Java, Python, Ruby, .NET: - 24.1.x - 25.1.x - 25.4.x - 25.7.x - 26.1.x - 26.4.x - 26.7.x Other versions of the SDK should not be used as they will no longer receive updates. _Moov's Go SDK follows a different versioning system. Visit the [Go SDK](https://github.com/moovfinancial/moov-go) for specific information._ ### Custom SDKs and direct API integrations If you generate your own SDK from our [OpenAPI specification](https://spec.speakeasy.com/moov/moov/api-v2026.04.00), or call the API directly, you are responsible for setting the `X-Moov-Version` header. Each OpenAPI spec includes the version it corresponds to in the `info.version` field. Configure your HTTP client or generated SDK to send this value as the `X-Moov-Version` header with every request. For example, if `info.version` is `v2026.04.00`, every request should include: Ask ```fallback X-Moov-Version: v2026.04.00 ``` Most OpenAPI generators do not automatically set header defaults, so you will likely need to configure this in a request interceptor, middleware, or client constructor — depending on your HTTP client or generated SDK.