Permissions
Access tokens use granular permissions to control which API resources they can access. Each token can have one or more permissions assigned.
Available Permissions
| Permission | Description | Endpoint |
|---|---|---|
products:read | Read access to the products catalog, including media, variants, options, and market pricing. | GET /api/v1/products |
orders:read | Read access to orders, including items, addresses, and fulfillment status. | GET /api/v1/orders |
webhooks:read | Read access to webhooks, including their name, type, event, URL, and status. | GET /api/v1/webhooks |
webhooks:write | Create, update, and delete webhooks. Maximum 20 webhooks per store. | POST/PUT/DELETE /api/v1/webhooks |
How Permissions Work
- Each token must have at least one permission assigned during creation.
- A token with
products:readcan only access the products endpoint. Requesting orders will return a403error. - A token with both
products:readandorders:readcan access both endpoints. - Permissions can be edited after creation. Go to Settings → Access tokens and click the token to update its permissions.
Permission Denied Response
When a token lacks the required permission for an endpoint, the API returns:
403 Forbidden
{
"status": "error",
"errors": [
"insufficient permissions, requires: orders:read"
]
}Best Practices
- Principle of least privilege — only grant the permissions each integration actually needs.
- Separate tokens per integration — create a dedicated token for each service or application.
- Restrict data access — use "Last 24 hours" for third-party integrations so they can only access the most recent data.
- Set expiration dates — for temporary integrations, use expiring tokens to limit exposure.
- Delete unused tokens — regularly review and remove tokens that are no longer in use.