Versioning

Fluveo serves one version of the /v1 API: 2026-05-27.dahlia. Every request is answered in that version, and every object and event has its shape. There is no older or newer version to choose.

The deprecation policy says which changes can land inside this version and which need a new one, and the changelog lists each change by date.

Send no Fluveo-Version header#

You do not need to send the Fluveo-Version header. A request without it runs in 2026-05-27.dahlia.

You send	Fluveo answers
No `Fluveo-Version` header	The request runs in `2026-05-27.dahlia`.
`Fluveo-Version: 2026-05-27.dahlia`	The request runs in `2026-05-27.dahlia`.
`Fluveo-Version` with any other version, an older one such as `2024-06-20` included	`400` with `type` `invalid_request_error`, no `code`, no `param`, and the message `Invalid Fluveo API version: <the value sent>`. Nothing runs.

Events and webhook endpoints#

Every event carries "api_version": "2026-05-27.dahlia". When you create a webhook endpoint, its api_version parameter is optional. Any value other than 2026-05-27.dahlia answers 400 with param api_version. See Webhooks.

Copying code written for another payments API#

Code written for another payments API often pins a different API version in a header, and SDKs send one on every request. On Fluveo such a request answers 400. Remove the header, and call the API over plain HTTP instead of an SDK.

Test it#

Call GET /v1/balance with no Fluveo-Version header. You get 200.
Check the api_version of any event in GET /v1/events. It is 2026-05-27.dahlia.

Next#

QuickstartMake your first test payment.AuthenticationSend your key on every request.Deprecation policySee which changes need a new API version.ChangelogRead what changed in the API and in these docs, by date.