The Zefort API is organized around REST. Our API uses predictable resource-oriented URLs, accepts JSON-encoded as well as form-encoded requests, returns JSON-encoded results, and uses standard HTTP verbs and error codes.
The Zefort API provides a comprehensive set of resources and operations to access all your content. The Zefort user interface is itself built on this API.
You can safely develop your integrations and experiment with the Zefort API on the sandbox server.
This documentation is published as an OpenAPI specification. There is a rich and growing ecosystem of tools available to work with OpenAPI descriptions. In fact, the official Zefort API reference manual is generated directly from the OpenAPI specification.
| Instance | API base URL | Description |
|---|---|---|
| Sandbox | https://sandbox.zefort.com/api/ | Sandbox for development and testing |
| EU production | https://my.zefort.com/api/ | Multitenant production, EU |
| US production | https://us.zefort.com/api/ | Multitenant production, US |
| Dedicated | https://your-instance-url/api/ | Enterprise customer dedicated instance |
The API for a particular Zefort instance is
available under the same domain name as the user interface, under the
/api/ prefix.
All API requests must be authenticated with an API key. You can manage your API keys in your account settings; this requires both the “Can manage account settings” and “Can manage users” permissions.
Each API key is tied to a user on your account. We suggest that you create separate users for your programs, instead of reusing user accounts of people who would normally use Zefort via the user interface. Using separate API users allows you to more easily control and monitor access for your program.
Obviously, an API key may give wide access to your account, so keep your API keys secure!
Authentication is performed with HTTP Basic Auth. Provide your API key as the username, and do not provide a password or leave it empty.
All API requests must be made over HTTPS.
While we expect the main structure of our API to be quite stable, we occasionally need to make backwards incompatible changes. API versions are distinguished with a dated version number string.
To ensure your code keeps working, we don't change your version until you are ready to upgrade.
When you make your first API request, the default API version in your
account settings is automatically set. After this, the API version
stays the same until you update it in your account settings. To call
a particular API version, pass the version number string in a
Zefort-Version header.
The supported version values are 2026-10-16, 2025-05-16, and 2024-08-01. A missing
or empty header uses your account's default version. If that default is not
set, the first valid request initializes it to the version in the header,
or the current version (2026-10-16) when the header is missing or empty.
An explicit version overrides an existing default only for that request.
Version 2026-10-16 introduces nullable boolean metadata for contracts and
parties: missing and explicitly cleared values return null, while supplied
values return true or false. Sending null clears the value; omitting a field
preserves it. This also applies to contract lists and nested party metadata.
Versions 2025-05-16 and 2024-08-01 continue returning false for unset boolean
metadata and reject explicit null writes. Existing account version pins do not
change automatically. Test an upgrade with Zefort-Version: 2026-10-16 before
changing your account's default version.
Version validation runs during API-key authentication or session authentication
with a selected profile. A malformed or unsupported nonempty header, such as
Zefort-Version: 2099-01-01, returns HTTP 400 with this JSON response:
{"detail": "Invalid version"}
The request is rejected before the requested operation runs. It does not change contract data or initialize or replace your account's default version. Anonymous requests and sessions without a selected profile do not perform this version validation.
We guarantee that all actively used API versions will remain available for at least three years from when they were introduced, as indicated by the API version. If a version you are using is scheduled for deprecation, you will receive advance warnings to the technical contact email addresses configured in your account settings.
The following changes are considered to be backwards compatible and do not cause a new version:
Objects IDs are opaque ASCII strings, and we guarantee that they will never be longer than 255 characters.