> For the complete documentation index, see [llms.txt](https://developer.abacum.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.abacum.ai/resources/build-a-client-that-survives-changes.md).

# Build a client that survives changes

How to write a client that keeps working when the API grows, and how to notice a change.

The API has one version. Every address starts with `/public-api/`, and there is no version number in it. The OpenAPI spec at `https://api.abacum.io/public-api/api-spec` describes the current API. The [Changelog](/resources/changelog.md) lists the changes to the API and to this documentation.

## Write the client to accept additions

* Ignore the JSON fields that you do not know. A response can gain a field.
* Do not depend on the order of the fields or of the columns in a data file. Read the `metadata` of each response. See [Data file format](/essentials/concepts/data-file-format.md).
* Treat a value that you do not know in a list of options as an unknown value, not as an error.
* Do not hard-code the structure of a model. Models are live, and their variables and dimensions change.

## Notice a change

The spec needs no token. Download it on a schedule, and compare it with your copy. This command prints a fingerprint of the current spec:

```bash
curl -s https://api.abacum.io/public-api/api-spec | shasum -a 256
```

When the fingerprint changes, read the [Changelog](/resources/changelog.md), then run your tests against the endpoints you use.

{% hint style="info" %}
The spec endpoint is public. Call it without an `Authorization` header.
{% endhint %}

## Keep your own tests

Add one test for each endpoint your integration calls. Check the status code and the fields that you read. A failing test tells you about a change before your users do.

If an answer of the API disagrees with this documentation, tell us. See [Support](/resources/support.md).