REST API

API Documentation.

Integrate matter plans and council form assembly directly into your practice-management system. Pull templates, resolve the matter.* token vocabulary, and assemble documents locally.

Base URL

https://www.openmatterplans.com/api/v1

Authentication

Three access modes. The public registry is open; community write operations use a browser session; PMS / document-assembly integrations use a per-account API key.

Public

Public registry + metadata. No credentials.

/matter-plans, /councils, /forms/:id/latest

Session

Community contributions by a verified practitioner (NextAuth browser sign-in).

/suggestions, /votes

API key

PMS / document-assembly. Generate a key under Profile → API Access. Every call is logged to your account.

/forms/:id/download, /field-sets/:slug, /councils/:id/report

Send your key as a header

curl https://www.openmatterplans.com/api/v1/field-sets/conveyancing-forms-au \
  -H "x-omn-api-key: omn_live_xxxxxxxxxxxxxxxx"

# or, equivalently:
  -H "Authorization: Bearer omn_live_xxxxxxxxxxxxxxxx"

Endpoints

Matter Plans & Community

Document Assembly (PMS integration)

Matter Plans (PMS integration)

GET

/api/v1/matter-plans

Session

Retrieve all legal matter plans currently defined in the registry, including their stages, milestones, and community-managed tasks.

// Response Body

[
  {
    "id": "8a3b8c2d-1a2b-3c4d-5e6f-7a8b9c0d1e2f",
    "title": "US Trademark Prosecution & Registration",
    "country_code": "US",
    "sali_area_of_law": "IP_TRADEMARK",
    "sali_process": "REGULATORY",
    "party_role": "LEAD_COUNSEL",
    "stages": [ { "title": "Preliminary Clearance & Search", "sequence_order": 1, "tasks": [ ... ] } ]
  }
]

Matter field vocabulary

Templates fill against matter.* tokens that resolve client-side against your matter payload (matter data never leaves the desktop). The canonical token list per practice area is served live - treat it as the source of truth rather than hard-coding it.

Pull the always-current vocabulary:GET /api/v1/field-sets/conveyancing-forms-au

Manifest field rules (PDF templates)

{ "token": "matter.ourFirmName" }Fill from the matter payload at that dotted path.

{ "token": "matter.fieldValues.settlement_date", "format": "DD/MM/YYYY" }Fill a value, formatted (dates only, v1).

{ "constant": "Search request" }Literal text, the same on every assembly.

{ "constant": true }On a checkbox: tick it unconditionally.

{ "rule": "checkIf", "expression": "matter.matterType == 'conveyancing_purchase'" }Tick / include only when the expression is true (== / != only).

{ "ai": "the searched property’s nearest cross street" }AI fills free-form text the catalogue cannot express. PII is obfuscated, so it cannot derive from client data - use tokens for those.

For a pdf_form template, download it and extract the embedded manifest.json (under /Names → /EmbeddedFiles); each AcroForm field maps to one rule above. checkIf supports == / != with single-quoted values; date format is DD/MM/YYYY (v1).

Streaming matter plans into your PMS

Plans evolve as practitioners refine them. Rather than re-pull every plan, track freshness off the contentHash and only download what changed. Each plan is bound to a resolved field set from the Matter Field Standard, so the tokens a PMS pre-fills against travel with the plan.

Step 1

List the catalog

GET /api/v1/matter-plans (keyed). Store each plan’s id + contentHash + fieldSetSlug. Page with updatedSince to poll cheaply.

Step 2

Compare contentHash

GET /api/v1/matter-plans/:id/latest. If the returned contentHash matches your cache, you are current - skip. If it differs, the plan changed.

Step 3

Download the body

GET /api/v1/matter-plans/:id/download (per-account key). Pull the full plan + resolved recommendedFieldSet, then update your cached hash.

Tasks carry field references

Each task can name the matter.* tokens it touches via pmsFieldRefs. Your PMS turns those into inline UI: when a task says “record the court date”, surface the matter.fieldValues.court_date field right on that task card so the practitioner fills it without leaving the checklist.

{
  "title": "Diarise the first return date",
  "pmsFieldRefs": ["matter.fieldValues.court_date"]
}
// -> PMS renders a date input for matter.fieldValues.court_date on this task,
//    typed from the field set (dataType "date", format "DD/MM/YYYY").

Every plan response carries planSchemaVersion. It is 1today. Gate your parser on it — if a future response reports a higher version than your client understands, skip the plan and prompt for an update rather than mis-reading a changed shape.