# Changes and versioning

What can change in the API without notice, what counts as a breaking change, and where changes are announced.

The API has one version, **v1**, in every REST path (`/api/public/v1/...`). The MCP server at `https://api.fundalyze.ai/mcp` serves the same tools.

**Breaking changes are announced in advance in the [API changelog](/developers/changelog).** Additions can arrive at any time.

## Additions (any time)

These do not break a client that follows the advice below, so they ship whenever they are ready and are listed in the changelog:

- New tools.
- New optional parameters on an existing tool, with a default that keeps today's behaviour.
- New fields in `data`, new keys in the [data dictionary](/developers/dictionary), and new rows as data arrives.
- Clearer tool descriptions, parameter descriptions and error messages.
- Higher limits.

## Breaking changes (announced in advance)

- Removing or renaming a tool, a parameter or a field of `data`.
- Changing what a field means, its unit or its type.
- Making an optional parameter required, or changing its default in a way that changes answers.

These are listed in the [API changelog](/developers/changelog) before they take effect, with what to change. Changes to the daily limits are also emailed to the people they affect, as the [Terms](/terms#api) say.

## Sources that can switch off

Each data source has its own switch, so we can turn one off without a release: if a source stops publishing, if its data turns out to be wrong, or if its terms change. While a source is off, its tools disappear from `tools/list` and the catalogue, and a call to one returns `404` (REST) or a "switched off" tool error (MCP). Everything else keeps working.

## Building so changes do not break you

- **In code, read `data`, not `text`.** `data` is the structured form, documented field by field on each [reference page](/developers/reference). `text` is laid out for a language model to read.
- **Ignore fields you do not know.** New fields appear in `data` as tools grow.
- **Do not hard-code the tool list.** Read it from `GET /api/public/v1/tools` (no key needed), as MCP clients do through `tools/list`.
- **Match errors on the status code**, not on the wording of `detail`.