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

Get startedPermissions and scopes

Permissions and scopes

What an API application may read and change, on the Records, Administration and Misc tabs; how OAuth scopes map to them; and what a missing permission answers.

Answer

Each API application has its own permissions on three tabs, Records, Administration and Misc. Every entry is Full Access (Write), Read Only Access (Read) or No Access (Disabled). A call the application lacks permission for answers HTTP 400 with code 50, not 403. User role restrictions do not apply to applications, and a credential works in one space only.

An API application's access is set per application, not per user, so every integration can have exactly the access it needs.

Where to set them

Open Administration › Units, Users & Roles › Applications, select the application and click Edit Permissions. The Application Permissions dialog has three tabs, and every entry on them takes one of three values:

In the dialog API value Meaning
Full Access Write Read and change
Read Only Access Read Read only
No Access Disabled No access

The API values are those of ApiPermissionEnum in the public GraphQL schema, where an application's permissions are the permissions field of ApiAccessEntity.

What each tab covers

Tab Entries in the dialog API names (permissions.…)
Records Accounts, Contacts, Leads, Opportunities, Tasks, Appointments, Emails, Messages, Projects, and one entry per custom entity records.accounts, .contacts, .leads, .opportunities, .tasks, .appointments, .emails, .messages, .projects, .customEntities
Administration Units, Users & Roles; Pipelines; Currencies; Products & Prices; Common Lists; Fields & Forms; Settings; Automation Hub; Security administration.unitsAndRoles, .pipelines, .currencies, .productsAndPrices, .commonList, .fieldsAndForms, .settings, .automationHub, .security
Misc Reports, Webhooks, Data, Documents, Others misc.reports, .webhooks, .data, .documents, .others

The Records tab uses your space's names for the record types, which an admin can rename. An integration that registers webhooks needs Full Access to Webhooks, on the Misc tab. One that saves processes or e-mail sequences needs at least Read Only Access to Emails when their e-mails use e-mail templates, and to Documents when a sequence's e-mails attach documents; without it the save answers code 50. Automation Hub and Security go up to Read Only Access: the dialog does not offer Full Access for them.

Only API applications of type Basic have Edit Permissions. An application that an AI connector created is of type OAuth and shows View Permissions, read only: its permissions come from the scopes the user approved.

What a missing permission answers

A call the application lacks the permission for answers HTTP 400 with code 50, ERROR_NOT_ENOUGH_PERMISSIONS. The API never answers 403, so check the code in the body, not only the status (errors). Fix it in Edit Permissions. In a batch, the whole call fails by default (batch operations).

User role restrictions

An application has no user role: its permissions are its own. The access to Task and Appointment types that a user role can restrict (release 6.4.0) has no effect on integrations, which keep using the types they are configured for.

One space per credential

An application belongs to one space, and its user name carries that space's ID. Its credentials are refused in any other space, whatever its permissions. An integration that works with several spaces needs an application in each.

OAuth scopes

The AI connectors sign in with OAuth, and the scopes the user approves become the permissions of an OAuth-type application: a .full scope becomes Write and a .read scope Read, on the matching entry. Settings, Automation Hub and Security can never be granted through OAuth, whatever the scopes. The scopes are listed in OAuth and scopes.

Least privilege

  • Create one application per integration, so you can change or revoke one without touching the others.
  • Give Read Only Access where the integration only reads, and No Access to everything it does not use.
  • Review the applications list from time to time: its Last usage column shows when each application last called the API.

Limits

  • Permissions are set per record type and per area.