> ## Documentation Index
> Fetch the complete documentation index at: https://developer-staging.secfix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Scopes

> The access you can grant an API key.

Every endpoint requires a scope. You grant scopes to an API key in **Settings → API**. A request
without the required scope returns `403 scope_required`.

## Access levels

You give each API key one of three access levels. Each level grants one or both scopes:

| Access level | Scopes | Grants |
| - | - | - |
| **Read** | `all:read` | Read access to every resource. |
| **Write** | `all:write` | Write access to every resource. Write doesn't include read. |
| **Full access** | `all:read` and `all:write` | Read and write access to every resource. |

`all:read` covers every `GET` endpoint. `all:write` covers every `POST`, `PATCH`, and `DELETE`
endpoint. In the inventory, write access lets you create, update, and delete `CUSTOM` and
`INFORMATION` assets. Every other category is read-only. See
[What you can write](https://developer-staging.secfix.com/guides/inventory.md#what-you-can-write).

## Who can grant an access level

An API key's token covers the **whole workspace**. Unlike a person in the Secfix app, it is never
limited to the assets it owns. So you can grant an access level only when your own role has the
matching permissions with access to **all** data, not only owned data:

| Access level | Your role needs, with access to all data |
| - | - |
| **Read** | View data in Inventory, Computers, Employees, and Groups, and view Frameworks |
| **Write** | Edit and edit sensitive (delete) in Inventory |
| **Full access** | Both of the above |

Otherwise the Secfix app doesn't let you create the API key or add that access level to it. You can
always keep an access level that someone else granted.

## New endpoints are covered automatically

Scopes are checked when a request arrives. `all:read` covers any read and `all:write` covers any
write, including endpoints added after you created the API key. You don't need to grant access
again when the API grows.

> [!NOTE]
>
> Sensitive resources added later, such as audit logs, connection credentials, or vendors, may need
> their own scope. They may then be unavailable to API keys that hold only `all:read` or
> `all:write`.

> [!NOTE]
>
> **Personal data under read access.** The [employees endpoints](https://developer-staging.secfix.com/guides/employees.md) return each
> employee's name and email address. `EMPLOYEE` assets in the inventory include the employee's
> `email`. Read access (`all:read`) returns this personal data. No separate scope protects it. Grant
> read access only to API keys that may see employee names and email addresses.

> [!NOTE]
>
> Per-resource scopes, such as read access to the inventory only, are planned for a future release.
> In v1, access is read and/or write across all resources.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.