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:
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.
Read related history
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.