Versioning

The &Open API uses calendar-based versioning. Versions follow a YYYY-MM format — the year and month a version was released — which keeps releases transparent and predictable.

Setting the API version

The AndOpen-API-Version header is required on every request. Pin it to a specific version so that future releases never change your integration's behaviour without you opting in.

curl "https://api.andopen.co/campaigns" \
  -H "Authorization: Bearer ao-v1-production-your_secret_here" \
  -H "AndOpen-API-Version: 2026-05"

The version header is checked before authentication. A request that omits the header, or sends a version the API does not recognise, is rejected with 400 and an unsupported_api_version error — before the token is examined:

{
  "errors": [
    {
      "type": "api_error",
      "code": "unsupported_api_version",
      "message": "Requests must include header 'AndOpen-API-Version: 2026-05'."
    }
  ]
}

Supported versions

Version	Status
2026-05	Current
2025-10	Supported

This documentation describes 2026-05. 2025-10 remains supported and keeps its own version of this reference.

What counts as a breaking change

A version is frozen, so within a single version we make only backward-compatible changes. Write your integration to tolerate them and you can stay on a version without surprises (see Forward compatibility).

Backward-compatible — shipped without a new version:

• Adding a new endpoint
• Adding a field to a response
• Adding an optional request parameter, or making a required one optional
• Adding a value to an enum, or a more specific error code for an already-failing case
• Widening the range of accepted values

Breaking — these only ever arrive in a new version:

• Removing, renaming, or retyping a response field
• Removing or renaming an endpoint
• Making an optional parameter required, or changing its default
• Changing the error code or HTTP status for an existing scenario
• Tightening validation on a request parameter — though protective tightening that rejects clearly invalid input (such as malformed emails) may ship within a version, noted in the changelog