---
title: Permissions and scopes
description: 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.
canonical: https://developers.coevera.com/get-started/permissions-and-scopes/
section: get-started
verification: schema
lastVerified: 2026-10-15
publisher: Coevera
---

# Permissions and scopes

**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](/webhooks/overview/) 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`](/reference/errors/#code-50), `ERROR_NOT_ENOUGH_PERMISSIONS`. The API never answers `403`,
so check the code in the body, not only the status ([errors](/concepts/errors/)). Fix it in
**Edit Permissions**. In a batch, the whole call fails by default
([batch operations](/concepts/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](/ai/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.