Developers
ChangelogSupportcoevera.comGet API keys
Set your API contextPick a region and space ID once. Every sample fills in your base URL.
Where do I find these?

In Coevera: open your space's API application and choose Show Access. It shows the space ID and the base URL, whose host starts with your region.

From the API: if you know the space ID, the discovery endpoint GET /api/discovery/spaces/{space_id} returns its region and base URLs, without credentials.

Only the region and space ID are kept, in this browser. Never paste a key or password here.

More in the quickstart

ConceptsData model

Data model

View as Markdown/concepts/data-model.mdOpen in ClaudeAsk Claude about this pageOpen in ChatGPTAsk ChatGPT about this page

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.

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 pairs them with the names the app shows, and the REST API reference 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.

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).

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 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).

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 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