Developers
Versioning
How it works#
A version is a date, like 2026-11-06, the first one. Each API key, organization key and Claude connection is pinned to the version that was current when it was made. Send Wilmo-Version to choose a version for one request. Every response says which version shaped it.
request has Wilmo-Version: <date> ?
| yes | no
v v
that version the version the key or Claude connection
was pinned to when it was made
| |
+------------+-------------+
v
response header Wilmo-Version: <the version that shaped it>curl https://app.wilmo.ai/api/v2/teams \
-H "Authorization: Bearer $WILMO_API_KEY" \
-H "Wilmo-Version: 2026-11-06"What needs a version#
Additive: any day
- A new operation
- A new optional input
- A new field in a response
- A new value in a list of values you only read
Breaking: a new version
- A field removed or renamed
- A new required input
- A field's type changed
- An operation removed
Write code that ignores fields it does not know, and additive changes never touch you. A breaking change only reaches callers who send or are pinned to its version or a newer one. Everyone else keeps the old shape.
Upgrade#
- Read the breaking changes between your version and the new one, below, for the operations you call.
- Change your code as each change's migration says.
- Send
Wilmo-Version: <new date>and test. Reverting the header is your rollback. - Ship. Optionally make a new key, which is pinned to the newest version, and retire the old one.
Using a coding agent? The migration skill walks it through these steps.
Changelog#
Also as JSON at https://app.wilmo.ai/api/public/v1/api-versions.
2026-11-06
CurrentThe first public API: teams, tickets and conversations, Autopilot metrics, analytics dashboards and reports; served over REST, MCP (Claude) and the wilmo CLI.
No changes to earlier versions.