API Access

The Lextree API is a cursor-paginated JSON API over your subscription’s data. Every key can read; a key created with write scope can also create, change, trash and restore records. It’s available on the Enterprise plan Enterprise . This page is an orientation to what it offers, and the full endpoint-by-endpoint reference lives in the interactive docs linked below. To make your first calls, follow Get Started with the API.

What the API Offers

The API exposes two families of data: the records you work with in the app, and the resources that attach to those records across every module.

Record Types and Related Resources

Record types are the records themselves — legal entities, contracts, boards, filings — each reachable at its own path. Related resources attach to records across every module: attachments (files), calendar events, workflows, and timeline entries. Both families share the same authentication, pagination, and error handling, so once you’ve queried one record type, every other type and resource works the same way.

Authentication and Endpoints

Every request carries a Bearer API key in the Authorization header. A record type’s path segment is its record_type slug — for example, entity_registry for legal entities:

curl https://app.example.com/api/v1/entity_registry \
  -H "Authorization: Bearer lt_live_ab12cd34_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

An interactive reference is served at /api/v1/docs (Swagger UI) — the authoritative source for every endpoint, parameter, and response shape.

Getting and Using a Key

An admin creates and revokes API keys on the Subscription page — see creating and revoking a key. A key is shown once, in full, at creation time and can’t be retrieved again, so store it securely.

A key is scoped to the whole subscription rather than to a person: it carries no access-group membership, so it can read across every module the subscription has enabled — including records an individual teammate wouldn’t see in the app. Scope who holds a key accordingly.

Keys do not expire on their own. They are all revoked, though, if the subscription moves to a plan without API access, and you need to create new keys after moving back (see what turns off on a downgrade).

Key Scopes

The admin chooses a key’s scope when creating it:

• Read-only: the key reads and never writes.
• Read and write: the key also creates, updates, trashes and restores.
• Read, write and purge: the key can also permanently delete records that are already in the trash.

Separately, the admin can tick Configuration access, which lets the key read and change how the subscription is set up. Configuration access is independent of the three scopes above: a read-only key can have it, and a purge key can go without it.

Neither the scope nor configuration access can be changed after creation. To widen or narrow a key, create a new one and revoke the old one. A request the key’s scope doesn’t allow is refused with 403 insufficient-scope.

What Each Scope Allows

• Records: any key reads records and the related resources attached to them. It can also read a file’s extracted text, a few pages at a time, when the file’s text_status is available (born-digital PDF, Word, RTF, text, HTML and CSV files). For any other status the call returns 409 text-unavailable, and you download the file instead. A write key creates, updates, trashes and restores records, calendar events, manual timeline entries and attachments. A purge key also deletes trashed ones for good.
• Reports and charts: any key runs a saved report and reads a chart’s picture. Each report and chart also carries a web_url, its page in the app, which you can hand to a person to open in their own session. A chart’s SVG refers to the Liberation Sans font without including it, so a PNG or PDF with the fonts built in has to come from the chart’s page in Lextree, using Download. A write key also creates, edits, trashes and restores reports and ownership charts, and regenerates a chart. Reporting and Ownership charts are Business and Enterprise features, and the API itself is Enterprise, so an API key reaches them on Enterprise. Charts also need the Entity Ownership module.
• Workflows: a write key launches a workflow, but only from a template an admin has opened to integrations. The key can rename a launched workflow or move its due date. It can’t complete, assign or otherwise work the workflow.
• Configuration: a key with configuration access reads each record type’s custom fields, sections, option lists and timeline states, plus the event templates, workflow templates and chart presets. Combined with a write scope, it also changes them, on the same rules Settings applies. Configuration deletes are final, because there is no trash to restore them from.

A key never manages people and access, billing, or the subscription itself. Configuration is the one part of Settings it can reach, and only when the key has configuration access. Every change a key makes appears in the audit history under the key’s name rather than a person’s.

Connecting an AI Assistant

The same API key works with the Lextree MCP server, which turns the API into tools an AI assistant can call. It uses the same authentication, module gating and key scope as the REST API. Nothing is installed: any MCP-compatible client connects to your Lextree address followed by /mcp.

• https://us.lextree.ai/mcp for a subscription on the US cell
• https://eu.lextree.ai/mcp for a subscription on the EU cell

The client sends the key as a Bearer token in the Authorization header, the same way a REST call does. Keep the key in whatever place your client stores secrets, not in a file you share.

The key’s scope sets the limit on what the assistant can do. On a read-only key the assistant can read, and every writing tool is refused with insufficient-scope. On a write key it can create, update, trash and restore. Tools that trash, delete or purge are marked destructive, so a client that honours those marks asks you before running them. On a key without configuration access, the configuration tools are refused the same way.

In a write session the assistant first asks which record types the key reaches and which fields of a record type are writable and required. It then makes the change as an ordinary API call. Each change is attributed to the key in the audit history, never to a person, so you can tell assistant edits from your team’s.

The assistant can hand you a link to a record, report or chart. The link opens in your own browser under your own permissions, and the assistant never opens it itself. To read a file, the assistant uses the read_file_text tool when the file’s text is available; for an image or a scanned PDF it needs the file’s download link and your client’s own tools. A file the assistant attaches travels inside the tool call, so a large document may not fit your client’s limit. The assistant can use the API’s attachment endpoint instead, but only where you have made the key available to the code it runs, which is your decision about where the credential lives.

Assistant traffic counts against the same rate limit as API calls; there is no separate allowance. For a step-by-step developer example of the calls an assistant makes on your behalf, see Get Started with the API.

Rate Limits and Full Reference

Requests are limited per subscription rather than per key, so all of a subscription’s keys share one budget. The budget is a token bucket that refills steadily. Each request spends tokens in proportion to its work: reading one record is cheap, a larger list page costs a little more, a search costs more again, and a write costs the most. A batch costs the sum of its items. A second cap limits how many requests run at once, holding writes to two at a time and chart regenerations to one. There are no daily caps. Exceeding a limit returns a 429 response telling you how long to wait before retrying.

For the complete set of endpoints, parameters, and response fields — including record-type schemas, filtering, and the related-resource catalog — use the Swagger UI at /api/v1/docs. This page covers only what you need to get started; the interactive reference is kept current automatically as your subscription’s schema changes.