API versioning and OpenAPI 3

The Griffin API is now versioned. When we make a change in our API, we'll release it as a new dated version. Your integration stays on the version it uses now until you decide to upgrade.

What's changing

• Dated API versions - each version is named by its release date in YYYY-MM-DD format, for example 2026-07-09. The changelog lists what changed in each version, endpoint by endpoint, so you can see what an upgrade involves before you start

• Test one endpoint at a time - add the Griffin-Version header and remove the v0 prefix on a request to call that endpoint on a different version. Nothing else in your integration changes, so you can move one endpoint at a time

• Your organisation's default version - requests without the header use your organisation's default version. You can change the default when you're ready to move your whole integration

• Events and webhooks follow your default version - new events are created in your organisation's default version, and that's the format your webhooks receive. Events created before you upgrade keep the format they were created in

• Rolling back - you can roll back to your previous version within 72 hours of upgrading. Each upgrade starts a new 72-hour window, and a rollback returns you only to the version you were on just before.

• OpenAPI 3 - we now publish the API spec in OpenAPI 3 for the current API and every new version. It works with current code generators and validators without converting from Swagger 2.0 first. You can download the spec from the API reference.

What does this mean for you?

• Existing organisations stay on their current API (v0). Your integration keeps working as it does today, and you don't need to do anything

• New sandbox organisations start on the latest version

Next steps

1. Read the changelog for the versions after the one you use

2. Send the Griffin-Version header on the endpoints you want to test, starting in the sandbox

Thanks for reading!

Stay connected:

 Read our docs

 Follow us on LinkedIn