Does the API cover everything the app does?

For reading, yes: contacts, workspaces, agreements with the conditions they are waiting on, money movements, and the ledger all come back typed. Writing is narrower on purpose. Contacts, workspaces, draft agreements, and participants you create outright; sending an agreement and confirming that money arrived are acts a person has to stand behind.

How do I get a token?

In the app, under Settings, then Developers. A token belongs to one organization, carries read-only or read-and-write access, and expires in ninety days. It is shown once at creation, so store it before you close the page.

Can I generate a client from the schema?

That is what it is for. The document at /openapi.json is OpenAPI 3.1 with every request and response typed, so the usual generators produce a client without hand-written models. Point your tooling at the file directly.

Why can’t the API confirm a payment or send an agreement?

Both are acts a person has to stand behind. Confirming that money arrived needs receiver-side evidence, which an organization-wide token is not, and publishing an agreement emails real people. The API proposes; a member confirms in the app, and the proposal records who did.

What happens if I retry a request?

Send an Idempotency-Key header on any POST and a repeat replays the original response instead of creating a second record. Reusing the same key with a different body is refused rather than guessed at.

Not yet. Generated clients cover most of what an SDK would. If you would rather we published one for your language, write to sales@termn.ai and say which.

Your agreements, in your own code.

A REST API over everything Termn tracks: contacts, workspaces, agreements and the conditions they are waiting on, the money moving against them, and the ledger that flattens all of it into what you are owed and owe. 20 calls in 7 groups, typed end to end.

Download the OpenAPI schema Browse it interactively

OpenAPI 3.1 · Version 1.0.0 · Base URL https://termn.ai

Your first call takes a token and a line

Create an organization token in the app under Settings, then Developers. It is shown once, so store it before you close the page. Send it as a bearer token on every request.

curl https://termn.ai/api/v1/me \
  -H "Authorization: Bearer $TERMN_TOKEN"

The reply names the organization the token belongs to and the scope it carries. Every other call is scoped to that organization: another organization’s record reads as not found, never as forbidden, so a wrong token never confirms that a record exists.

Every endpoint, by group

13 of the 20 calls are reads. The token column names the ones a read-only token is refused for.

Identity 1 call

Who the calling token belongs to.

Call	What it does	Token
GET /api/v1/me	Describe the calling token	Read

Contacts 4 calls

People and entities your organization does business with. Organization-scoped and reusable; agreements reference contacts rather than copying them.

Call	What it does	Token
GET /api/v1/contacts	List contacts	Read
POST /api/v1/contacts	Create a contact	Read and write
GET /api/v1/contacts/{contact_id}	Fetch one contact	Read
PATCH /api/v1/contacts/{contact_id}	Update a contact	Read and write

Workspaces 4 calls

One workspace per deal or matter. Agreements live inside a workspace.

Call	What it does	Token
GET /api/v1/workspaces	List workspaces	Read
POST /api/v1/workspaces	Create a workspace	Read and write
GET /api/v1/workspaces/{workspace_id}	Fetch one workspace	Read
POST /api/v1/workspaces/{workspace_id}/contacts	Reference a contact from a workspace	Read and write

Agreements 5 calls

Agreements with their ordered stages and gates. Create drafts here; publishing an agreement to participants happens in the Termn app.

Call	What it does	Token
GET /api/v1/agreements	List agreements	Read
POST /api/v1/agreements	Create a draft agreement	Read and write
GET /api/v1/agreements/{agreement_id}	Fetch one agreement	Read
GET /api/v1/agreements/{agreement_id}/information	Answers to an agreement's information requests	Read
POST /api/v1/agreements/{agreement_id}/participants	Add a participant to an agreement	Read and write

Money movement 2 calls

Read-only, deliberately. Authorizing a payment and confirming that one arrived are evidence-gated acts: only receiver-side evidence at recipient-confirmed assurance or better may reconcile a movement, and a sender's acknowledgement never proves receipt. An organization-wide API token is not that evidence, so those transitions are performed by a person in the Termn app and observed here.

Call	What it does	Token
GET /api/v1/movements	List money movements	Read
GET /api/v1/movements/{movement_id}	Fetch one money movement	Read

Ledger 1 call

Every obligation and asset across all workspaces, in one flat list.

Call	What it does	Token
GET /api/v1/ledger	List ledger rows	Read

Proposals 3 calls

The only door to protected effects. A machine credential may propose publishing or cancelling an agreement; a member of the organization reviews the plain-language summary at confirm_url in the Termn app and confirms or declines it there. Nothing executes until they do. Undecided proposals expire after 72 hours.

Call	What it does	Token
POST /api/v1/proposals	Propose a protected effect	Read and write
GET /api/v1/proposals	List proposals	Read
GET /api/v1/proposals/{proposal_id}	Fetch one proposal	Read

Paths are shown in full: the base URL above plus any row is the URL you call. Every request and response body is typed in the schema, so point a generator at it rather than transcribing fields by hand.

What the API will not do for you

These hold for every call, from every client, on every token.

Confirm that money arrived: Money movements are read-only here, deliberately. A sender reporting that they sent it is stored as their claim; reconciling it takes receiver-side evidence and a person with authority accepting it, and an organization-wide token is neither.
Email your participants: Publishing an agreement and cancelling one never execute from a token. Your integration proposes the effect and gets back a confirmation link; a member reads the plain-language summary in the app and confirms or declines. Undecided proposals expire after 72 hours.
Reach another organization: Every call resolves the token’s organization before it loads anything. A record outside it returns 404 with no hint that it exists, so an id from somewhere else leaks nothing.
Hand back the wire instructions: A payment tells you its state and who confirmed it. The instructions themselves, bank details, tokens, and webhook secrets appear in no response at all.
Create the same record twice: Send an Idempotency-Key header on any POST and a retry replays the original response. The same key with a different body is refused rather than guessed at.
Change quietly: Every call writes an audit row in the transaction it commits: the token, the operation, the objects, the outcome. Your own text and your participants’ details stay out of the logs.

Failures come back in one shape

Every failure is the same envelope with a stable error.code to branch on, a message for a person to read, and a request id to quote to us. Validation failures add a list naming each field. These are the statuses to handle.

Status	What it means
401	Missing, malformed, expired, or revoked token.
403	This token is read-only.
404	No such record in your organization.
409	Idempotency-Key reused with a different request.
422	The request did not pass validation.
500	Unexpected failure on our side.

not_found · unauthenticated · forbidden · invalid_request · method_not_allowed · conflict · internal_error

Webhooks, and the other way in

Rather than polling, register an endpoint in the app under Settings, then Developers. Each event is posted as JSON with an HMAC-SHA-256 signature over the timestamp and body. Delivery is at-least-once, so treat a repeat as normal and check the event id.

Write against the REST API

For scripts, back-office jobs, and your own product.

Generate a client. The schema is OpenAPI 3.1 with every body typed, so your generator writes the models.
Read the ledger. One flat list of everything owed and owing across every workspace, rather than walking agreements.
Retry safely. An idempotency key on each POST makes a repeat harmless.

Connect an MCP client

For agents that work the follow-up rather than call endpoints.

Point it at /mcp. Same token, same organization scope, same audit trail.
Read the conditions. Every tool runs an API operation underneath, so no tool has a power the API lacks.
Hand the send to a person. The agent proposes; a member confirms. How that works.

The API and the schema cost nothing, and drafting through them is free exactly as it is in the app. $149 activates the workspace when you are ready to send. See all pricing.

Common questions

Does the API cover everything the app does?: For reading, yes: contacts, workspaces, agreements with the conditions they are waiting on, money movements, and the ledger all come back typed. Writing is narrower on purpose. Contacts, workspaces, draft agreements, and participants you create outright; sending an agreement and confirming that money arrived are acts a person has to stand behind.
How do I get a token?: In the app, under Settings, then Developers. A token belongs to one organization, carries read-only or read-and-write access, and expires in ninety days. It is shown once at creation, so store it before you close the page.
Can I generate a client from the schema?: That is what it is for. The document at /openapi.json is OpenAPI 3.1 with every request and response typed, so the usual generators produce a client without hand-written models. Point your tooling at the file directly.
Why can’t the API confirm a payment or send an agreement?: Both are acts a person has to stand behind. Confirming that money arrived needs receiver-side evidence, which an organization-wide token is not, and publishing an agreement emails real people. The API proposes; a member confirms in the app, and the proposal records who did.
What happens if I retry a request?: Send an Idempotency-Key header on any POST and a repeat replays the original response instead of creating a second record. Reusing the same key with a different body is refused rather than guessed at.
Is there an SDK?: Not yet. Generated clients cover most of what an SDK would. If you would rather we published one for your language, write to sales@termn.ai and say which.