Skip to main content

​
Scopes

Scopes define what a developer application can read or change. Start narrow, test the integration, and add write scopes only when needed.
Endpoint pages in the API reference show exact scope requirements for each operation.

​
Scope groups

products.read

Read products, variations, and catalog metadata.

products.write

Create, update, and archive products and variations.

categories.read

Read categories and category trees.

categories.write

Create, update, and archive categories.

vendors.read

Read vendor profile data.

vendors.write

Create, update, and deactivate vendor profiles.

​
Starter bundles

Read catalog

products.read categories.read vendors.read locations.read

Manage catalog

products.read products.write categories.read categories.write vendors.read vendors.write locations.read

Monitor usage

usage.read

​
Scope table

​
Choosing scopes

Start with read access

Use read scopes during initial development so the first requests cannot change tenant data.

Add write access per workflow

Add products.write, categories.write, or vendors.write only after the integration is ready to create, update, archive, or deactivate those records.

Separate systems when access differs

Use separate developer applications when two systems need different scope bundles or rotation schedules.
Keep separate applications for separate jobs when different systems need different permissions.