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: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:
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
Reporting or data warehouse sync
Reporting or data warehouse sync
Read-only across the resources you export, plus
welcome:read. For example:
welcome:read projects:read milestones:read invoices:read suppliers:read.Project intake from another system
Project intake from another system
welcome:read projects:write projects:read — write to create the project, read to confirm
the result and poll its state.Bid evaluation workflow
Bid evaluation workflow
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.AI assistant via the MCP server
AI assistant via the MCP server
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.
