Identifiers

Open in the interactive reference

Almost every record has an id. Use it in the path to read, update or delete the record, as in GET /accounting/customers/{id}. A nested endpoint names the child's id as well, as in /accounting/products/{id}/product-lines/{productLineId}.

A field that refers to another record is usually named after it: customerId for a customer, entityId for a legal entity. The name does not always match; a warehouse, for example, is referenced as locationId. Check a field's description to see which record it refers to.

A legal entity is a company within your tenant that keeps its own books. Many records belong to one, and creating them needs its entityId. List your legal entities with GET /base/entities; each one's id is the entityId other endpoints take.

Most identifiers are UUID strings, and some are numbers. Each field states its type on its endpoint. Treat every identifier as opaque: do not parse it, derive meaning from it, or sort by it.

A few references can't be followed through the API: the record they point to has no endpoint, or the field holds a numeric key rather than the UUID the record's endpoint takes. The field's description says when this applies.

A readable code such as accountNumber can also identify a record within its scope, but it is an ordinary field. Endpoints address records by id, apart from a few that name another identifier in their path.

Examples

A record and a reference

{
  "id": "9f2c6a10-7d34-4c8e-9b21-5a0f3e6d81b7",
  "entityId": "3b7d5e9c-1a24-4f80-9c6d-2e8f70b13a45"
}