Skip to main content
The API can change without notice. We aim to keep it stable, and we will try to warn you before a change that could break your tool. We cannot promise that. Build your tool so that a change fails loudly and you notice it.

​
What we aim for

We aim to change v1 only by adding things:
  • new endpoints;
  • new optional query parameters;
  • new fields in a response;
  • new values in a list of allowed values (an enum).
None of these should break a tool that follows the rules below.

​
How to build a tool that survives change

  • Ignore fields you do not know. A response can gain fields at any time.
  • Treat an unknown enum value as “other”. For example, a new event type should not crash your tool.
  • Check for a field before you read it. Fields that a key’s scopes do not allow are left out.
  • Check the status code of every response. Fail loudly on an error. Do not quietly write an empty sheet.
  • Branch on the error code, never on the message.

​
Where changes are listed

Every change to the API is in the changelog. The version of the API document (info.version in the OpenAPI file) goes up with each change.

​
Beta

The API is in beta. While it is in beta, changes may come more often. Tell us what you build and what breaks: contact us.