Welcome to the Exizent developer docs

Exizent is the platform that probate and estate administration firms use to run their cases — from the first instruction through to final distribution. It holds the matter, the people involved, the assets and liabilities that make up the estate, the documents, and the work that moves it all forward.

These docs are for developers connecting their own systems to that platform. Whether you are syncing matters from a practice management system, pulling an estate position into a report, or building a product that works alongside Exizent, this is where you start.

What's here

Guides — the pages in this section. Task-shaped walkthroughs: how to authenticate, how to carry out a particular piece of work end to end, and the conventions and gotchas worth knowing before you write code.

API Reference — every endpoint, with its parameters, request and response schemas, and status codes. Reach for it once you know which call you want; come back to the guides when you want to know which call you want.

Our APIs

More APIs will appear here as we open them up. The authentication described below is common to all of them, so what you build once will carry over.

Getting started

1. Authenticate with a machine-to-machine client — create an application, get client credentials, and exchange them for an access token. Every endpoint needs one, so do this first.
2. Manage the deceased and people on a case — a worked walkthrough against the Cases API: create a case, read it back, and keep it up to date.
3. Upload and download documents — attach files to a case or an estate item, follow them through the malware scan, and get them back.
4. Browse the API Reference for everything else.

Environments

Every Exizent API is available in two environments. Build and test against Sandbox first — it is entirely separate, with its own credentials and its own data, so nothing you do there touches live estates.

Credentials are not shared between environments. You will create an application in each.

Conventions

A handful of rules hold across our APIs, so they are worth reading once rather than rediscovering per endpoint.

JSON throughout. Send Content-Type: application/json on requests with a body; responses come back as JSON.

camelCase properties. firstName, dateOfDeath, buildingNameOrFlatNumber.

Enums are strings, not numbers. Send "maritalStatus": "Married", not "maritalStatus": 0. Values are case-sensitive and spelled in PascalCase.

Identifiers are GUIDs. Cases, people, organisations, estate items and documents are all identified by a UUID, e.g. 979989d9-4f3e-4253-9a1d-9f94adb00493.

Dates. Date-only fields on request bodies are declared as yyyy-MM-dd, for example "dateOfDeath": "2021-09-06". Responses return full ISO-8601 timestamps, e.g. "2021-09-06T00:00:00Z".

Lowercase URLs. Routes are served in lowercase — /cases/{caseId}/people, not /Cases/{caseId}/People.

Everything is scoped to your company. Your credentials belong to exactly one firm, and a token issued to it can only ever see and change that firm's data.

PUT replaces, it does not merge. This one catches people out. A PUT sends the complete new state of the resource, and any field you leave out is cleared rather than left alone. Always read the current resource, change the fields you mean to change, and send the whole object back. The deceased and people guide shows the pattern.

Errors

Failures come back as RFC 7807 problem details:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "detail": null,
  "errors": {
    "lastName": ["The LastName field is required."]
  }
}

A 404 on something you believe exists almost always means the token belongs to a different company.

Cases API concepts

A little vocabulary goes a long way when reading the Cases API guides and reference.

Company — a law firm, or a company providing probate services. Your credentials belong to one, and that company owns the cases you can reach.

User — a member of the firm. Users hold roles that decide what they may do:

Case — a single estate administration, often referred to as a matter. It is the root of everything: people, estate items, expenses and documents all hang off a case, and every endpoint below /cases/{caseId} operates within one.

Deceased — the person who has died. Exactly one per case, created at the same moment as the case itself.

Person — an individual connected to the case: a beneficiary, executor, creditor, trustee and so on. A case has many, and one person can hold several roles at once.

Organisation — a body connected to the case, such as a charity receiving a legacy.

Trust — a trust connected to the estate.

Estate item — an asset or a liability logged against the estate: a bank account, a property, a shareholding, a credit card balance.

Document — a stored file, held against the case or against a particular estate item.

Support

Something not behaving as documented, or a question these pages do not answer? Contact us at [email protected].