Permissions

Every connection has a set of permissions. Each REST endpoint and MCP tool lists the permissions it needs, and a request fails with 403 and error.code: missing_permission if one is missing.

Permission dependencies

Some permissions only make sense together. For example, creating a job requires reading jobs and customers. When you choose a create permission in Settings → API connections, the read permissions it depends on are selected automatically.

Dependencies are requirements, not automatic grants: the connection must actually hold every permission in the set. The table below is generated from the permission map of the API version this site documents.

Permission	Requires directly	Complete set to grant
customer_locations:create	customer_locations:read, customers:read	customer_locations:create, customer_locations:read, customers:read
customer_locations:read	customers:read	customer_locations:read, customers:read
customers:create	customers:read	customers:create, customers:read
customers:read	—	customers:read
invoices:create	customers:read, invoices:read, products:read	customers:read, invoices:create, invoices:read, products:read
invoices:read	customers:read	customers:read, invoices:read
job_items:create	job_items:read, jobs:read, products:read	job_items:create, job_items:read, jobs:read, products:read
job_items:read	jobs:read	job_items:read, jobs:read
jobs:create	customers:read, jobs:read	customers:read, jobs:create, jobs:read
jobs:read	—	jobs:read
members:invite	members:read	members:invite, members:read
members:read	—	members:read
products:create	products:read	products:create, products:read
products:read	—	products:read
quotes:create	customers:read, products:read, quotes:read	customers:read, products:read, quotes:create, quotes:read
quotes:read	customers:read	customers:read, quotes:read
timesheets:read	members:read	members:read, timesheets:read

Inputs that need extra permissions

Some optional inputs need permissions beyond the endpoint's own. For example, creating a job with a location_id also needs customer_locations:read. Each create page lists these under Permissions.

Fields that need extra permissions

Reads return a record's own fields with the endpoint's permission. Summaries of related records need the related permission too. For example, a job's customer summary needs customers:read. Without it, the field is left out rather than causing an error.

For example, timesheet entries include the related job's name only when the connection has jobs:read.

Invitation authority

Member invitations need more than members:invite and members:read: a person with authority to invite must stand behind the connection.

• REST connections: the owner or admin who created the connection with invitation access, or who last saved its permissions, is its sponsor. They must still be an eligible owner or admin.
• MCP connections: the owner or admin who approved the connection must still be one.

If that person loses their role, invitation endpoints return 403 operation_forbidden, and the MCP invitation tools disappear from the client's tool list. See Create a member invitation.

Features that must also be enabled

A permission doesn't turn a feature on. Some features also need FieldTask to enable them, such as timed job scheduling, job items, quotes and invoices. Others depend on your organization's own settings: invoice creation needs invoicing enabled for the organization, and member invitations need an eligible owner or admin behind the connection.

Changing permissions

Connection	Add a permission	Remove a permission
API token	Manage → select it. Applies from the next request.	Applies from the next request.
OAuth client	Manage → select it, then include it in scope when requesting a token.	Applies from the next request.
AI assistant (MCP)	Waits for approval: the person who connected the assistant must reconnect and approve, then refresh tools.	Applies from the next request.

Existing access tokens never gain permissions they weren't issued with.