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

Get startedREST or GraphQL?

REST or GraphQL?

View as Markdown/get-started/rest-or-graphql.mdOpen in ClaudeAsk Claude about this pageOpen in ChatGPTAsk ChatGPT about this page

The Coevera API has a REST and a GraphQL interface over the same data. How they differ in paths and naming, and which business actions only GraphQL has.

Answer

Both reach the same data with the same credentials. REST suits create, read, update and delete, with kebab-case query parameters and snake_case bodies. GraphQL uses camelCase names and has the business actions REST lacks: qualifying a lead exists only there, while move, change owner and lost have a REST PATCH that skips the actions' extras.

Every page of these docs shows both interfaces where both exist. They share the space, the records, the permissions and the API application's credentials; they differ in shape and in what they can do.

Side by side

REST GraphQL
Endpoint /api/v100/rest/spaces/{space_id}/entities/{Entity}, one path per entity POST /api/v100/app/space/{space_id}/graphql/public, one endpoint; a GET answers 405
Query parameters kebab-case: load-only, order-by, filter-op, include-deleted (querying) Arguments in camelCase: first, after, orderBy, includeDeleted
Field names snake_case, in bodies and responses: owner_id, step_id, is_archived camelCase: ownerId, stepId, isArchived
Lists success, total, page_info, data (pagination) totalCount, pageInfo, edges
Date-times A space between date and time: 2026-10-14 09:00:00+00:00 A T: 2026-10-14T09:00:00+00:00 (dates and time zones)
Writes POST, PATCH, DELETE and batch endpoints per entity Mutations such as createAccount
Business actions None; a PATCH of the field instead (below) Qualify, move, change owner, archive and more
Contract The OpenAPI document, described in the REST reference The public GraphQL schema, described in the GraphQL reference

The quickstart makes the same first call both ways, and the downloads have both contracts as files.

Business actions

The CRM's actions on leads and opportunities are GraphQL mutations. REST has only create, read, update and delete, so for most actions it changes the field instead:

Action GraphQL What REST can do instead
Qualify qualifyLead Nothing. Qualifying converts the lead into an opportunity with the same id; REST cannot reproduce it.
Move moveOpportunity, moveLead PATCH step_id
Change owner changeOwnershipOpportunity, and one per entity PATCH owner_id
Won A move to the pipeline's last step; there is no separate won action PATCH step_id to the last step
Lost archiveOpportunity: archiving; there is no separate lost action PATCH is_archived

A REST PATCH changes the record and writes the same history entries and webhook events as the GraphQL action. It skips what the action adds:

  • a memo (memoText);
  • completing activities (completeActivityIds);
  • accepting or archiving quotes (acceptQuoteIds, archiveQuoteIds);
  • keeping the old owner as an editor (keepOwnerAsEditor);
  • transferring linked records (transferLinkedRecords);
  • the lost form's required fields.

Use the GraphQL action when you need any of these. The lead lifecycle recipe qualifies a lead, moves the opportunity and changes its owner with them, and create an account with contacts shows the same writes in both APIs.

Choosing

  • Synchronising records (create, read, update, delete, batches): REST. Every entity has the same operations, which makes it the steadier choice for long-lived integrations.
  • Business actions (qualify, move with a memo, change owner with linked records): GraphQL.
  • Fetching related records in one call: either. REST has expand; GraphQL selects nested fields.

Removals from the public GraphQL schema are announced in the API changelog before they happen. For long-lived integrations, prefer REST for create, read, update and delete, and GraphQL for the business actions REST does not have.

Limits

  • REST has no action endpoints: no qualify, no move with a memo, no change of owner that transfers linked records.
  • The public GraphQL schema is the one at …/graphql/public. The CRM's own app schema is a different, internal one: do not build on it.