Versioning

Brightalk uses date-based contract versions so a server can choose the API behavior it integrates against.

Use an unversioned URL

All requests use the production base URL https://api.brightalk.ai. Version numbers are not part of the path; for example, create a call at POST /calls.

Send Brightalk-Version

Send the supported date version explicitly on every request:

Brightalk-Version: 2026-07-16

Every response echoes the version actually applied in its Brightalk-Version header. Keep the header value in configuration so an intentional contract upgrade can be reviewed and tested.

Understand omission and defaults

Each organization has a pinned default API version. If a request omits Brightalk-Version, Brightalk uses that pinned default and still returns the applied version in the response header. Omission does not select an arbitrary newest version.

Handle an unsupported version

An unknown or retired value returns 400 unsupported_version. The optional machine-readable details list supported versions:

{
  "error": {
    "code": "unsupported_version",
    "message": "The requested API version is not supported.",
    "request_id": "req_demo_001",
    "details": {
      "supported_versions": ["2026-07-16"]
    }
  }
}

Breaking response or behavior changes require another date version. Additive response fields may appear within a version, so clients should ignore unknown response fields.

Get started

API fundamentals

Core concepts

Guides

Release information

API reference

Use an unversioned URL

Send Brightalk-Version

Understand omission and defaults

Handle an unsupported version

​Use an unversioned URL

​Send Brightalk-Version

​Understand omission and defaults

​Handle an unsupported version

Use an unversioned URL

Send Brightalk-Version

Understand omission and defaults

Handle an unsupported version