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

AI & MCPOAuth and scopes

OAuth and scopes

View as Markdown/ai/oauth-and-scopes.mdOpen in ClaudeAsk Claude about this pageOpen in ChatGPTAsk ChatGPT about this page

How the AI connectors sign in with OAuth 2.0 and PKCE, the 15 scopes the MCP server requires, what each grants, and what OAuth cannot grant.

Answer

The AI connectors sign in with the OAuth 2.0 authorization code flow and PKCE (S256). The user approves 15 scopes: each .full scope grants write and each .read scope grants read on the matching permissions, and settings, Automation Hub and security permissions are never granted. OAuth applications for your own integrations are not yet available; use an API application.

OAuth is how a user lets an assistant act in their Coevera space without giving it a password. On this site it is documented only as it applies to the MCP server and the AI connectors.

How sign-in works

  1. The client sends the user to Coevera's authorization endpoint with its client ID, a redirect URL from the connector's allow-list, the scopes and a PKCE challenge (S256).
  2. The user signs in to Coevera and picks a space. Only active spaces with an active subscription are offered.
  3. The consent screen lists the scopes. Coevera accepts the consent only if the user holds the Admin API Access right in that space and the connector is active for it.
  4. The client exchanges the code for an access token at the token endpoint, authenticating with its client secret (client_secret_basic or client_secret_post) and the PKCE verifier.
  5. The client calls POST /mcp with Authorization: Bearer and the token. The server checks the token on every request.

The endpoints are published in the MCP server's discovery document:

Text
https://mcp-server.coevera.com/.well-known/oauth-authorization-server
Item Value (discovery document, 2026-10-14)
Issuer https://mcp-server.coevera.com
Authorization endpoint https://crm.coevera.com/oauth2/app/authorize
Token endpoint https://crm.coevera.com/oauth2/app/token
Grant types authorization_code
PKCE methods S256
Client authentication client_secret_basic, client_secret_post

Access tokens are valid for one hour. There is no dynamic client registration: the clients are registered by Coevera, behind the Claude Connector, the ChatGPT Connector and the MCP Connector.

Scopes

The server requires these 15 scopes. A token that lacks one is answered 403.

Scope Access Covers
accounts.full Write Accounts
contacts.full Write Contacts
leads.full Write Leads
opportunities.full Write Opportunities
tasks.full Write Tasks
appointments.full Write Appointments
emails.full Write Emails
messages.full Write Text messages
documents.full Write Documents (files); needed for uploads
products_and_prices.full Write Products and price lists
projects.read Read Projects
currencies.read Read Currencies
pipelines.read Read Pipelines and their steps
fields_and_forms.read Read Fields and forms
units_and_roles.read Read Sales units and roles

A .full scope becomes Write, and a .read scope Read, on the matching entry of the application's permissions (the Records, Administration and Misc sections; see permissions and scopes). The settings, Automation Hub and security permissions can never be granted through OAuth, whatever the scopes.

The scopes cap what the connector can do; they never extend it. The assistant still sees only what the signed-in user can see.

The OAuth application in your space

Approving the consent creates an application of type OAuth in the space, listed under Administration › Units, Users & Roles › Applications. Its name and permissions are read-only there, and it has no Show Access, because an OAuth application has no password to show.

OAuth for your own integration

OAuth applications for third-party integrations are not yet available: there is no way to register your own OAuth client. Integrations authenticate as an API application, with its user name and password over HTTP Basic: see authentication and permissions and scopes, or start with the quickstart.