--- title: Data model description: How Coevera records fit together. Entities and their plural paths, owners and sales units, the relation rows that link records, and where your own fields and entities are described. canonical: https://developers.coevera.com/concepts/data-model/ section: concepts verification: schema lastVerified: 2026-10-15 publisher: Coevera --- # Data model **Answer:** Each record type is an entity with a plural path, such as /entities/Accounts. Records point at each other through id fields such as owner_id, and through relation entities such as ContactAccountRelations. Every record except Leads and Tasks has an owner, a Client (user). Your custom fields and custom entities are described only in your space's own spec. Every integration starts from the same questions: which entity holds the data, how two records are linked, and who owns them. The names below are the API's; the [glossary](/concepts/glossary/) pairs them with the names the app shows, and the [REST API reference](/reference/rest/) has a page for every entity. ## Entities and their paths Each record type is an entity. REST paths use the plural name, `/entities/Accounts`, `/entities/Opportunities`, `/entities/OpptyProductRelations`; the GraphQL repository is the singular name in camelCase, `entities { account { … } }`. A singular or misspelt path is refused with HTTP 404, code 2006 `ERROR_UNKNOWN_TYPE`. | Entity | What it holds | | ----------------------- | -------------------------------------------------------------------------- | | `Accounts` | Companies and organisations | | `Contacts` | People, usually linked to accounts | | `Leads` | Unqualified sales opportunities | | `Opportunities` | Qualified deals in a pipeline, on a step (`Steps`) of a `Pipelines` record | | `OpptyProductRelations` | Product line items on an opportunity; the catalogue is `Products` | | `Quotes` | Quotes for an opportunity | | `Projects` | Projects | | `Tasks`, `Appointments` | The two kinds of activity | | `Notes` | Notes attached to a record | | `Emails`, `Memos` | Logged e-mails, and internal messages (shown in the app as **Message**) | | `CloudObjects` | Documents and files; `CloudObjectRelations` attaches them to records | | `Clients` | The space's users; their roles are `MasterRights` | | `SalesUnits` | Sales units, which group users and records | | `Data` | The options of dropdown fields | There is no `Messages` entity: `/entities/Messages` answers 404, code 2006. Logged e-mails are `Emails` and internal messages are `Memos`, both linked to records through `MessageRelations`. Leads and opportunities share one base, so their relation fields are called `lead_oppty_id`. ## Owners and sales units `owner_id` (shown in the app as **Owner**) is required on every record except Leads and Tasks: those two may be unassigned, while Appointments, Accounts, Contacts, Opportunities, Quotes, Projects and custom entity records always have an owner. A lead still needs a sales unit: send `owner_id`, or `unit_id` alone for an unassigned lead; without either, the create answers 422. The owner is a `Clients` record, a user of the space. Users are looked up by `email`, not `email1` as on contacts and accounts: `filter[email]=dana.whitfield@example.com` on `/entities/Clients`. `unit_id` (shown as **Sales unit**) places the record in a `SalesUnits` record, which decides who else in the space sees it. ## How records link A record points at another one in two ways: - **An id field**, such as `owner_id` or `account_id`, holds the other record's ID. Write it to link records; filter on it to find them. - **A relation field** with the bare name, such as `owner`, returns the related record's URL. Add `expand=owner` to a list request to get the record itself ([querying](/concepts/querying/#load-only-and-expand)). Many-to-many links are records of their own, in relation entities: | Relation entity | Links | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ContactAccountRelations` | Contacts and accounts, with `position` and `is_primary`; the [create an account with contacts](/recipes/create-account-with-contacts/) recipe writes them | | `LeadOpptyAccountRelations`, `LeadOpptyContactRelations` | Leads and opportunities, and their accounts and contacts | | `QuoteAccountRelations`, `QuoteContactRelations` | Quotes, and their accounts and contacts | | `ActivityRelations` | Tasks and appointments, and the records they are about | | `MessageRelations` | E-mails and messages, and the records they are about | | `CloudObjectRelations` | Documents, and the records they are attached to | Relation records outlive their records: deleting a contact or an account leaves its `ContactAccountRelations` active, still pointing at the deleted record. Delete them on their own ([batch operations](/concepts/batch-operations/#batch-endpoints)). ## Your own fields and entities The published spec describes the standard entities and fields every space has. Your space's custom fields (API names starting with `cf_`) and custom entities (`CE_` names) are in your space's own spec, served with your credentials at `https://{region}.api.coevera.com/api/v100/rest/spaces/{space_id}/openapi.json`, and in the [Fields](/concepts/fields-and-custom-fields/) and `Entities` endpoints. ## Limits | Limit | Details | | -------------------------- | ------------------------------------------------------------------------------------------------------------ | | Owner | Required on every record except Leads and Tasks; a lead without an owner needs a `unit_id` | | Custom fields and entities | Not in the published spec; only in your space's own spec and the Fields and Entities endpoints | | Relation records | Not deleted with the records they link | | Entity names | `Messages`, `Documents` and `Users` are not entities: use `Emails` and `Memos`, `CloudObjects` and `Clients` |