to navigate · to open See all results

Authentication and permissions

Create and manage tokens, choose permissions, and keep requests scoped to the correct organization.

Last updated

Send a bearer token

Every customer API request requires these headers:

HTTP
Authorization: Bearer YOUR_API_TOKEN
Accept: application/json

Use Content-Type: application/json for JSON request bodies. Tokens are created in Settings → API Access by an active account administrator. Select a 30-day, 90-day, or one-year lifetime. Tokens are shown once; store them securely and use one named token per integration.

Organization scope

A token stays tied to the organization where it was created, even when its creator switches organizations in the app. Do not send tenant_id or account_id to choose an organization; list and timeline requests prohibit these fields. Use a separate token for each organization.

Access stops when the token expires or is revoked, or when its creator is deactivated, removed from the organization, or no longer an account administrator. Manage and revoke tokens in API Access. Create and deploy a replacement token before revoking the old one during rotation.

Record permissions

Replace resource with assets, people, locations, or subscriptions.

Permission Allows
resource:read Record lists, details, and timeline history.
resource:create Creation options and creating records.
resource:update Updating record details with PUT or PATCH.
resource:delete Permanently deleting a record.

These permissions are independent. Write access does not imply Read. Creation options require Create, even though the request uses GET.

Workflow permissions

Permission suffix Allows
:todos List, create, edit, delete, and look up assignees for to-dos.
:events Add notes; for assets, also add lifecycle events.
:assignments Manage assignment links and look up choices.
:lifecycle Asset acquisition, warranty, condition, and decommission actions; subscription contracts and status actions; people/location status and location spaces.

Workflow GET requests require the workflow’s permission. Read Only tokens cannot list workflow to-dos or assignment choices. Subscription billing and its options require subscriptions:update.

Actions with multiple permissions

Asset subscription assignments require assets:assignments and subscriptions:update. Subscription assignment endpoints require subscriptions:assignments and the target resource’s :update permission. People/location assignment endpoints likewise need the source resource’s :assignments and the target’s :update. These extra requirements also apply to their GET lists and options.

Asset decommissioning requires assets:lifecycle and assets:delete, including its options lookup. Subscription cancellation and retirement require subscriptions:lifecycle and subscriptions:delete. Deleting a location space requires locations:lifecycle and locations:delete.

The parent record’s Read permission allows its timeline. Related asset events also require assets:read; related subscription events require subscriptions:read. References only reveal resources your token can read. A person’s timeline can therefore contain fewer events with a narrowly scoped token. Use the timeline endpoint pages for details.