Resource identifiers

Efimis resource IDs combine a resource-type prefix with a GUID represented without dashes:

<object-type>_<guid-without-dashes>

Examples include:

entity_3f7b2c5808b84fb69afab36731fd9812
client_70e1f8b0d63846f5a0222e03314ac49d
matter_22635a10c993592cb52c083f346aa950
employee_c7d7359affb94552b6d0b7469a072396

Treat IDs as opaque values

Store and send the complete ID returned by Efimis. Treat it as an opaque value: do not remove the prefix, add dashes to the GUID portion, or reconstruct an ID from another field.

Related resources have different IDs

An entity and each role held by that entity have separate identifiers. For example:

• entity_... identifies the shared person, organisation, or group record;
• client_... identifies the client role held by that entity; and
• employee_... identifies the employee role held by that entity.

Use the identifier required by the API field. A clientId expects a client-role ID, while a clientEntityId expects the underlying entity ID.

Resource IDs and user-facing numbers

A resource ID is not the same as a user-facing number or code. For example, a matter can have both:

• an Efimis resource ID such as matter_22635a10c993592cb52c083f346aa950; and
• a firm-defined matter number displayed to users.

Use the resource ID for API relationships. Use the firm-defined number or code for display and business workflows.

Creating IDs

Use the ID returned by Efimis unless an endpoint explicitly requires the caller to supply one. For example, webhook subscription IDs are caller-supplied but must still follow the documented webhook_<guid-without-dashes> format.