API changes

Code you write against /v1 keeps working. Inside /v1, the API only grows.

What may be added to /v1

These come without a new version, so write your code to take them in its stride:

• new routes;
• new fields in an answer;
• new optional fields in a request;
• new error codes;
• new values of a field that takes one of a set, such as a new Monitor type or a new event.

Ignore a field you do not know, and handle a value or a code you do not know, rather than fail on it.

What needs /v2

Removing or renaming a field, making a field required, or changing what a field holds or means comes only in a new version, /v2. Once /v2 is out, /v1 keeps answering for at least 12 months. A route on its way out answers with the Deprecation and Sunset headers, so your code can warn you.

The MCP server’s tools

The tools of the MCP server keep the same promise. A new tool, a new optional input or a new field in an answer may come at any time. A tool is never renamed, and a tool that reads never starts to change things. A tool is removed only after it has been marked deprecated for at least 12 months: its description then starts “Deprecated”, and names the tool to use instead.

Change log

• 2026-10. GET /status is new: what is not ok now, in every Project the token reaches or one, in one request.
• 2026-10. The Monitor list takes q=, which finds a Monitor by part of its name or target, whatever the case.
• 2026-10. The MCP server is new: an AI assistant reads and acts on your Monitors with an API token.