Wabery API versioning and deprecation

The URL pins the major API version. The Wabery-Version header pins behavior. Wabery does not ship silent breaking changes. See the deprecation policy for notice periods.

https://api.wabery.com/v1

Pin a behavior version

Send Wabery-Version with the dated version your integration was tested against. The current version is 2026-06-18:

curl https://api.wabery.com/v1/me \
  -H "Authorization: Bearer $WABERY_API_KEY" \
  -H "Wabery-Version: 2026-06-18"

Every handled REST response returns Wabery-Version so a caller can verify the behavior that served the request. Without the request header, Wabery uses the organization’s pinned version and then the current default.

Within /v1, Wabery makes additive, backward-compatible changes without creating a new dated version. A breaking response or behavior change requires a new dated version. A new URL major such as /v2 is reserved for a broader contract break that cannot be represented safely by the dated header.

Deprecation and sunset policy

Wabery gives at least 180 days’ notice before retiring a supported public API version, except when an urgent security or legal requirement makes that period unsafe or impossible. During the notice period, affected responses include:

• Deprecation: @<unix-timestamp> with the date deprecation begins, following RFC 9745.
• Sunset: <HTTP-date> with the planned removal date, following RFC 8594.
• Link: <https://wabery.com/docs/deprecation/>; rel="deprecation" pointing to the deprecation and sunset policy. Current responses send Deprecation: ?0 (RFC 9745) until a version is actually deprecated.

The OpenAPI document marks affected operations with deprecated: true and publishes the same dates through Wabery extensions. Wabery also announces the change in the developer documentation and package changelogs. No public REST version is currently scheduled for sunset.

Agent guidance

Agents should use /v1, send a known Wabery-Version, record the response version, and treat Deprecation or Sunset as a prompt to plan migration. Do not automatically switch a production integration to a new dated version without testing its read and write paths.