API changelog

Changes to the API, newest first.

Compatibility policy

We may do these without notice, so write your integration to tolerate them:

  • Add a new endpoint.
  • Add a field to a response. Parse leniently — do not fail on a key you did not expect.
  • Add an optional request parameter.
  • Add a new value to an enumerated field, including a new webhook event type. Ignore what you do not recognise rather than throwing.

We will not do these without a new API version and notice:

  • Remove or rename a field in a response.
  • Change a field's type.
  • Add a required request parameter to an existing endpoint.
  • Change what a status code means.
  • Remove an endpoint.

Security fixes are the exception. If an endpoint is exposing something it should not, we will close it and tell you afterwards.

Changes

  1. added

    API keys authenticate

    Organization API keys now authenticate requests. Keys carry scopes, an optional expiry and an optional IP allowlist, all enforced.

    A key names its own organization, so the X-Organization-ID header is no longer required. Sending one that names a different organization is refused rather than ignored.

    Keys created before this date have been revoked and marked legacy_never_functional. They never authenticated anything, so nothing that worked has stopped working — but they cannot be migrated, because only a salted hash of each was ever stored. Create replacements in the dashboard.

    Creating a key now requires at least one scope. A key with none can do nothing, and accepting one only produced a credential that failed at its first call.

  2. added

    Developer documentation

    This documentation. The API reference is generated from the running application on every release, so it cannot drift from what the API actually serves.

    The OpenAPI 3.1 document and a Postman collection are downloadable from the API overview.

Product changes beyond the API are on the release notes.