Manage the deceased and people on a case

Every case has exactly one deceased — the person who has died — and any number of people: the executors, beneficiaries, creditors, trustees and others connected to the estate. This guide walks through creating them, reading them back, and updating them.

You will need an access token with read:case, create:case and update:case. See Authenticate with a machine-to-machine client.

All paths below are relative to your environment's base URL:

How these resources fit together

The deceased and people behave differently, and knowing which is which saves a lot of guesswork:

• The deceased is part of the case. It is created when the case is created — there is no "create a deceased" call — and from then on you update it in place. It has no id of its own; you address it through the case.
• People are a collection. You add them one at a time, each gets its own id, and you update or replace them individually.
• Neither has its own GET. You read both back from the case: GET /cases/{id} returns the deceased as an object and the people as an array.

One rule governs every update on this page:

PUT replaces the whole resource. Any field you leave out of the body is cleared, not left as it was. Always read the current state, change what you mean to change, and send the complete object back.

Create a case with its deceased

POST /cases

The deceased is supplied inline, and only three of its fields are required at this point — enough to open a case on the day of instruction. Everything else is filled in later with the update call below.

curl --request POST \
  --url https://cases.api.testing.exizent.com/cases \
  --header 'Authorization: Bearer {{access_token}}' \
  --header 'Content-Type: application/json' \
  --data '{
    "companyCaseId": "MATTER-2026-0417",
    "caseOwnerUsername": "[email protected]",
    "deceased": {
      "firstName": "Peter",
      "lastName": "Reid",
      "dateOfDeath": "2021-09-06T00:00:00Z"
    }
  }'

201 Created

{
  "id": "979989d9-4f3e-4253-9a1d-9f94adb00493"
}

Keep that id. It is the case id used by every call that follows.

Requires the create:case scope.

Retrieve the case, the deceased and the people

GET /cases/{id}

curl --request GET \
  --url https://cases.api.testing.exizent.com/cases/979989d9-4f3e-4253-9a1d-9f94adb00493 \
  --header 'Authorization: Bearer {{access_token}}'

200 OK — the full case. The parts this guide cares about:

{
  "id": "979989d9-4f3e-4253-9a1d-9f94adb00493",
  "companyCaseId": "MATTER-2026-0417",
  "updatedAt": "2026-09-15T10:22:41.117Z",
  "deceased": {
    "title": "Mx",
    "firstName": "Peter",
    "lastName": "Reid",
    "middleName": null,
    "otherNames": [],
    "maidenName": null,
    "dateOfBirth": "1961-02-21T00:00:00Z",
    "niNumber": "QQ 123456 C",
    "occupation": "Software Architect",
    "address": {
      "buildingNumber": "8",
      "buildingNameOrFlatNumber": null,
      "streetName": "Example Street",
      "city": "Peterhead",
      "postcode": "AB42 1AA"
    },
    "willDetails": {
      "hasWill": true,
      "hasBeenAnnexed": false,
      "willDate": "2019-11-02T00:00:00Z",
      "originalWillLocation": "Firm safe, Edinburgh"
    },
    "dateOfDeath": "2021-09-06T00:00:00Z",
    "placeOfDeath": "Example City",
    "domicile": "GB-SCT",
    "maritalStatus": "Widowed",
    "hasSurvivingSpouseOrCivilPartner": false,
    "hasDeathCertificate": true,
    "notes": "Some notes about the deceased"
  },
  "people": [
    {
      "id": "06fd5add-09c4-46f3-9def-7da32ee2c153",
      "firstName": "Joe",
      "lastName": "Tester",
      "roles": ["Executor", "Beneficiary"],
      "executorStatus": "Sole",
      "relationshipToDeceased": "BiologicalChild",
      "isSignatory": true,
      "createdAt": "2026-09-15T09:14:02.551Z",
      "linkedTo": []
    }
  ],
  "estateItems": [],
  "grossEstateValue": 0,
  "netEstateValue": 0
}

Two fields on a person are read-only and returned only here: createdAt, and linkedTo — the other resources on the case that reference this person, such as a distribution or a jointly-owned estate item.

A 404 means either that no such case exists, or that it belongs to another company. Requires read:case.

Update the deceased

PUT /cases/{id}/deceased

This is the call that fills in everything the case-creation body could not carry.

Remember that it replaces the deceased outright. Read the case first, merge your changes into the deceased object you got back, and send the whole thing — otherwise the name you did not mention is the name you just erased.

curl --request PUT \
  --url https://cases.api.testing.exizent.com/cases/979989d9-4f3e-4253-9a1d-9f94adb00493/deceased \
  --header 'Authorization: Bearer {{access_token}}' \
  --header 'Content-Type: application/json' \
  --data '{
    "title": "Mx",
    "firstName": "Peter",
    "lastName": "Reid",
    "middleName": null,
    "otherNames": ["Pete"],
    "maidenName": null,
    "dateOfBirth": "1961-02-21",
    "niNumber": "QQ 123456 C",
    "occupation": "Software Architect",
    "address": {
      "buildingNumber": "8",
      "buildingNameOrFlatNumber": null,
      "streetName": "Example Street",
      "city": "Peterhead",
      "postcode": "AB42 1AA"
    },
    "willDetails": {
      "hasWill": true,
      "hasBeenAnnexed": false,
      "willDate": "2019-11-02",
      "originalWillLocation": "Firm safe, Edinburgh"
    },
    "dateOfDeath": "2021-09-06",
    "placeOfDeath": "Example City",
    "domicile": "GB-SCT",
    "hasDeathCertificate": true,
    "ihtReferenceNumber": null,
    "uniqueTaxpayerReference": null,
    "hasSurvivingSpouseOrCivilPartner": false,
    "maritalStatus": "Widowed",
    "maritalStatusDate": null,
    "notes": "Some notes about the deceased"
  }'

200 OK, with no body. Read the case again if you want to confirm the stored state.

Deceased fields

maritalStatus — one of Single, Married, CivilPartnership, Divorced, Widowed, CivilPartnershipDissolved, JudiciallySeparated.

sheriffdom — one of GlasgowAndStrathkelvin, GrampianHighlandAndIslands, LothianAndBorders, NorthStrathclyde, SouthStrathclydeDumfriesAndGalloway, TaysideCentralAndFife, WithoutAnyFixedOrKnownDomicileExceptTheSameWasInScotland, Other.

Will details — hasWill (boolean), hasBeenAnnexed (boolean), willDate (date), originalWillLocation (string).

Requires update:case.

Add a person to a case

POST /cases/{caseId}/people

The API assigns the id. Only firstName and lastName are required, but a person is far more useful with their roles and relationship recorded.

curl --request POST \
  --url https://cases.api.testing.exizent.com/cases/979989d9-4f3e-4253-9a1d-9f94adb00493/people \
  --header 'Authorization: Bearer {{access_token}}' \
  --header 'Content-Type: application/json' \
  --data '{
    "roles": ["Executor", "Beneficiary"],
    "executorStatus": "Sole",
    "title": "Mr",
    "firstName": "Joe",
    "lastName": "Tester",
    "relationshipToDeceased": "BiologicalChild",
    "dateOfBirth": "1990-07-19",
    "contactNumber": "07700 900123",
    "emailAddress": "[email protected]",
    "occupation": "Teacher",
    "niNumber": "QQ 987654 D",
    "address": {
      "buildingNumber": "8",
      "buildingNameOrFlatNumber": null,
      "streetName": "Example Street",
      "city": "Example City",
      "postcode": "AB1 2BA"
    },
    "bankDetails": {
      "name": "Bank of Scotland",
      "nameOnAccount": "Joe G Tester",
      "accountNumber": "12345678",
      "sortCode": "11-22-33"
    },
    "isSignatory": true,
    "notes": null
  }'

201 Created

{
  "id": "06fd5add-09c4-46f3-9def-7da32ee2c153"
}

Store that id — it is how you address this person from now on.

Requires update:case. Adding a person changes an existing case, so create:case is not what is needed here.

Update a person

PUT /cases/{caseId}/people/{personId}

Same rule as the deceased: the body replaces the person entirely. Read the case, take the person out of the people array, apply your changes, send it all back.

curl --request PUT \
  --url https://cases.api.testing.exizent.com/cases/979989d9-4f3e-4253-9a1d-9f94adb00493/people/06fd5add-09c4-46f3-9def-7da32ee2c153 \
  --header 'Authorization: Bearer {{access_token}}' \
  --header 'Content-Type: application/json' \
  --data '{
    "roles": ["Executor", "Beneficiary"],
    "executorStatus": "JointLead",
    "title": "Mr",
    "firstName": "Joe",
    "lastName": "Tester",
    "relationshipToDeceased": "BiologicalChild",
    "dateOfBirth": "1990-07-19",
    "contactNumber": "07700 900123",
    "emailAddress": "[email protected]",
    "occupation": "Teacher",
    "niNumber": "QQ 987654 D",
    "address": {
      "buildingNumber": "8",
      "buildingNameOrFlatNumber": null,
      "streetName": "Example Street",
      "city": "Example City",
      "postcode": "AB1 2BA"
    },
    "bankDetails": {
      "name": "Bank of Scotland",
      "nameOnAccount": "Joe G Tester",
      "accountNumber": "12345678",
      "sortCode": "11-22-33"
    },
    "isSignatory": true,
    "notes": "Prefers contact by email"
  }'

204 No Content — the person existed and was updated.

201 Created with { "id": "..." } — no person on the case had that id, so one was created with it. This makes the endpoint an upsert, which is handy when your own system owns the identifiers: choose a GUID on your side and PUT to it without checking first.

404 Not Found — the case does not exist, or belongs to another company.

Requires update:case.

Person fields

roles — any of Child, Executor, Beneficiary, Creditor, Trustee, SurvivingJointOwner, ProfessionalExecutorSignatory, PreDeceasedSpouse, ParentOrGuardian, LeadTrusteeParentOrGuardian. A person can hold several at once.

relationshipToDeceased — one of Husband, Wife, Spouse, CivilPartner, Partner, BiologicalChild, AdoptedChild, StepChild, Son, Daughter, Mother, Father, Sister, Brother, Niece, Nephew, Cousin, Grandchild, GreatGrandchild, MotherInLaw, FatherInLaw, SonInLaw, DaughterInLaw, BrotherInLaw, SisterInLaw, Friend, Solicitor, BusinessPartner, Organisation, Charity, Other.

Entitlement — for beneficiaries: pecuniaryAmount (a fixed cash legacy), residuaryType and residuaryAmount (a share of the residue), and specificGiftIds (the estate items left to them specifically).

Address

Used by both the deceased and people. Every field is optional.

Note the spelling buildingNameOrFlatNumber.

A note on dates

The two styles you will see are not an inconsistency to work around, just a difference worth knowing:

• Case creation (POST /cases) takes deceased.dateOfDeath as a full timestamp: "2021-09-06T00:00:00Z".
• The deceased and people update endpoints take date-only values: "2021-09-06".
• Responses always return full ISO-8601 timestamps.

If you are round-tripping a value you read from GET /cases/{id} back into a PUT, take the date part.

Putting it together

A typical first sync of a matter from your own system:

1. POST /cases with your matter reference and the three known facts about the deceased. Keep the returned case id.
2. PUT /cases/{id}/deceased with the full details once you have them — address, will, NI number, marital status.
3. POST /cases/{caseId}/people once per executor and beneficiary. Keep each returned person id against your own record.
4. GET /cases/{id} to confirm what was stored.
5. On any later change, GET the case, merge into the object you got back, and PUT the complete resource.

That last step is the one to build in from the start. Sending a partial PUT is the most common way to lose data through this API, and it is entirely avoidable.

Errors

Validation failures come back as problem details:

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

Stuck on something? [email protected].