Developers
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

AI & MCPBuild agents on the API

Build agents on the API

When to build your own agent or automation on the REST or GraphQL API instead of the MCP server, and how it authenticates.

Answer

To build your own agent or automation, call the Coevera REST or GraphQL API with an API application's user name and password over HTTP Basic. The MCP server suits assistants that a person signs in to and supervises; it offers 20 fixed tools. OAuth applications for third-party integrations are not yet available, so API applications are the documented path.

MCP server or API?

MCP server REST and GraphQL API
Who it acts as The person who signed in and approved the scopes An API application, with the permissions an admin gave it
Sign-in OAuth, through a connector that Coevera activates The application's user name and password over HTTP Basic
Coverage 20 tools over the main record types, custom entities included Every entity in the space, custom entities included, plus fields and pipelines
Reacting to changes Not available: the assistant has to ask Webhooks for record events
Business actions Bulk move, archive and qualify; change of owner Qualify, move and change of owner in GraphQL (REST or GraphQL?)
Where it runs United States, for every space Your space's own region
Limits Burst per token and sustained per space; thresholds not published A monthly call quota by plan (pricing)

Use the MCP server when a person works through an assistant such as Claude or ChatGPT. Use the API when your own code runs without a person in the loop: a sync, a scheduled job, a back-office agent, or a service that reacts to webhooks.

Authenticate as an API application

An API application is a user type for integrations. It has its own user name and password and its own permissions, so each integration gets only the access it needs, and its writes show its name in the record history. The quickstart shows how to create one and make a first call, and authentication how its credentials are sent and rotated.

OAuth applications for third-party integrations are not yet available. OAuth exists only behind the AI connectors; see OAuth and scopes.

Tips for agent builders

  • Give the application only the permissions the agent needs. Permissions are set per application, in the Records, Administration and Misc sections (permissions and scopes).
  • Read the schema of the actual space. Spaces differ: custom fields, custom entities and renamed entities. An authenticated request for /api/v100/rest/spaces/{space_id}/openapi.json returns an OpenAPI document built for that space, its custom fields and custom entities included (tools).
  • Branch on the error code. A missing permission answers 400 with code 50, not 403; errors lists what each status means.
  • Retry on 429. Wait for the seconds in Retry-After, then retry (rate limits and retries).
  • Check every item of a batch. A batch write can succeed for some records and fail for others; read the result for each item (batch operations).
  • Give the agent these docs. Every page here is also plain Markdown, listed in llms.txt; see Use these docs with AI.