Permissions and project scope
An API token represents a user. The server still checks that user’s company, project and resource permissions.
Project membership
Section titled “Project membership”A user must have access to the project involved in the request. Knowing a case or plan ID does not grant access to it. Keep the project ID with the resource IDs your integration stores.
Read and write permissions
Section titled “Read and write permissions”A token that can list cases may not be allowed to create, edit, delete or assign them. Use a user role that matches the workflow’s needs and verify each intended write in your integration’s project.
Assignment and ownership
Section titled “Assignment and ownership”Assignees must be valid project members with the appropriate execution access. Defaults and existing assignments can be preserved by the plan assignment behavior; do not assume every assignment call replaces them.
BDD-managed definitions are owned by feature files. An edit permission does not make ordinary API edits appropriate for those definitions.
Region and sharing
Section titled “Region and sharing”Use the same account region for all calls in a workflow. A report shared with a project is accessible to authorized project members; that sharing setting does not make it anonymously readable.
Investigate a denied request
Section titled “Investigate a denied request”Check the API host, token owner, project membership, resource/project pairing and required operation permission. Include the method and status code when contacting support, with credentials and token-bearing URLs removed.