Skip to main content

How scopes work

Each endpoint requires a specific scope. You choose which scopes to request when you exchange your credentials for a token, as a space-separated string:
You are granted the intersection of what you asked for and what your OAuth client is permitted to hold — so always read the scope field on the token response rather than assuming the request was honoured in full. Calling an endpoint without its scope returns 403 with error: insufficient_scope, naming the scope required and the scopes you hold:
Request the narrowest set that does the job. A reporting integration needs only :read scopes; nothing that merely reads data should hold a :write scope.

Naming

Scopes follow <resource>:<action>, where the action is read or write. A :write scope covers creating and updating that resource — it does not imply the matching :read scope, so request both if you need to read what you have written. welcome:read is a special case: it grants GET /welcome, the whoami endpoint. Include it in every token so your integration can confirm its own identity and granted scopes.

Available scopes

The token endpoint advertises a wider catalogue than the table above. Scopes that no documented endpoint currently uses are omitted here — if you need one of them, contact support@zivio.com before building against it.

Choosing scopes

Read-only across the resources you export, plus welcome:read. For example: welcome:read projects:read milestones:read invoices:read suppliers:read.
welcome:read projects:write projects:read — write to create the project, read to confirm the result and poll its state.
welcome:read projects:read bids:read bid_evaluations:read bid_evaluations:write — add bids:write only if the integration also shortlists, selects or eliminates bids.
Start read-only — welcome:read plus the :read scopes for the resources you want queried. Add :write scopes only once you are comfortable with an assistant mutating live records. See MCP server.