Skip to contentSaltar al contenidoAle nan kontni anПерейти к содержимомуדלג לתוכן
EstateDraftFL

Developers

Build on the firm’s record without moving it

A firm’s systems read where its matters stand, hear of what changed, and propose what should happen next. The record stays here, behind the firm’s walls; the firm decides.

Reviewed 2026-10-01

The three doors

  • Live

    The REST API

    Matters, deadlines, receipts, the agenda and the capability catalogue — paginated honestly, each answer carrying how far it can be trusted. One write: a proposal for the firm to decide.

  • Live

    Signed webhooks

    Nine events as they happen — ids and states only, signed with the endpoint's own secret, delivered at least once, never about a matter with a wall.

  • Off until the platform turns it on

    The MCP server

    The same reads as tools for an AI assistant, under the same key, walls and limits — and one tool that files a proposal, never an action.

The credential boundary

Keys are the firm’s. Its admin mints each one in the firm’s console (Firm settings → API access), choosing what it may do (its scopes), whose view it reads (the attorney’s, or only what a client may see), which matters (the whole firm, or a list), and when it expires. A key is shown once; only its SHA-256 fingerprint is kept. Every request is checked against the key’s grant and the firm’s walls, at the moment it is made.

A key can never

  • read a matter with a wall (team-only, or with a screen) — it is never listed, counted or found;
  • read a name, a document's contents or a person's words — the API carries ids, states, dates and hashes;
  • execute anything — the one write files a proposal the firm's attorneys decide;
  • see another firm, or anything on the consumer platform;
  • outlive its grant — it expires when the firm said, is revoked the moment the firm revokes it, and is revoked when the admin who minted it leaves (unless the firm approved it as a named service's).

Failure is part of the contract

An unreadable read is a 503, never an empty list
It says retryable, with Retry-After. Zero rows is a 200 with an empty list — and the two are never confused.
Null is unknown, not empty
A part that could not be read comes back null, and the answer’s verification status drops to unknown.
has_more is never a guess
Each page reads one row past its limit. The cursor is a position only; every page is authorized again.
A write happens once
Every write carries an Idempotency-Key: the same request replays the first answer; a different one with the same key is refused.
Every delivery is signed
Verify the signature before trusting the body; de-duplicate by the event id; order by the timestamp.
Limits are stated, not discovered
Every answer says how much of the key’s per-minute lane is left and when it refills.

What each capability does and refuses is published in the firm capability catalogue; a receipt from the API can be checked by anyone at the receipt verifier. The machine-readable contract is the OpenAPI document.