Skip to main content
Every endpoint requires a scope. Scopes are granted to your application in the Developer Console; a request without sufficient access is rejected with 403 scope_required.

​
Access levels

In the Developer Console you grant an application one of three access levels, which map to two scopes: all:read satisfies any read (GET) endpoint and all:write satisfies any write (PATCH) endpoint, evaluated at request time.

​
Forward-covering

The scopes are forward-covering. Because all:read satisfies any read check and all:write satisfies any write check at request time, an application automatically gains access to new resource types as their endpoints ship — with no re-grant and no re-consent. Grant an access level once and it keeps covering the API as it grows.
Materially sensitive resource classes (for example audit logs, connection credentials, or vendors) may be gated behind an explicit scope when they ship, even for applications holding all:read / all:write.
Employee PII under read access. EMPLOYEE-category assets returned by the inventory endpoints include the employee’s email address (personally identifiable information). This PII is surfaced under read access (all:read) — it is not gated behind a separate scope. Grant read access only to applications you intend to give access to employee email addresses.
Finer-grained, per-resource scopes (for example read-only access to just the inventory) are planned for a future release. In v1, access is read and/or write across all resources.