Every call is authenticated with a bearer credential in the Authorization header:
Two kinds of token work. Pick by how your integration runs:
Personal Access Tokens
PATs look like inf_pat_… and carry explicit scopes:
READ: required for every GET.WRITE: required for POST, PATCH, and DELETE.
OAuth access tokens
The access token your connected app obtains through the OAuth 2.1 + PKCE flow works on the Developer API as-is: same header, no separate registration. Two things to know:
- The token acts as the user who authorized the app: workspace admins and members can read and write; viewers are read-only.
- The token must belong to a user. Service-to-service tokens are rejected with
403.
Refresh the access token with your refresh token as usual; nothing else about your API calls changes.
Auth failures
Auth failures are returned by the gateway with an empty body. The status code carries the meaning:
A mistyped path or unsupported method under /v1 also returns 401 (deny-by-default), not 404. If a valid token is suddenly getting 401s, check the path before the credential.
