Roles and permissions
Commerce Layer supports a granular access control system on a resource level. Each access token gets a specific set of permissions. The client and the authorization flow determine your permitted actions for each resource.
Sales channel applications support client_credentials, password and refresh_token grant types. Given their limited permissions, they can be safely used in client-side applications.
Sales channel applications that authenticate through client_credentials get the following permissions.
For security reasons sales channel applications can read resource lists only for skus, sku_options and prices. Getting a list for all the other resources is not allowed. For example, a sales channel is authorized to get /api/orders/xYZkjABcde but not /api/orders endpoint.
​ | Create | Read | Update | Delete | Restrictions |
SKUs | ​ | ​✅ | ​ | ​ | SKUs with stock items in the market inventory model and a price in the market price list. |
SKU options | ​ | ​✅​ | ​ | ​ | ​ |
Prices | ​ | ​✅​ | ​ | ​ | Prices associated to the market price list. |
Orders | ​✅​ | ​✅​ | ✅​ | ​ | Can be read if "draft", "pending" or "placed" and updated if "draft" or "pending" (single resource only). |
Line items | ​✅​ | ​✅​ | ​✅​ | ​✅​ | Can be read if belonging to "draft", "pending" or "placed" orders and updated if belonging to "draft" or "pending" orders (single resource only). |
Addresses | ​✅ | ​✅​ | ​✅​ | ​✅​ | Single resource only. |
Shipments | ​ | ​✅​ | ​✅​ | ​ | Can be read if belonging to "draft", "pending" or "placed" orders and updated if belonging to "draft" or "pending" orders (single resource only). |
Shipment line items | ​ | ​✅​ | ​ | ​ | Can be read if belonging to shipments associated to "draft", "pending" or "placed" orders (single resource only). |
Shipping methods | ​ | ​✅​ | ​ | ​ | Single resource or as shipment available shipping methods. |
Payment methods | ​ | ​✅​ | ​ | ​ | Single resource or as order available payment methods. |
Payment sources | ​✅​ | ​✅​ | ​✅​ | ​✅​ | Can be read if belonging to "draft", "pending" or "placed" orders and updated/deleted if belonging to "draft" or "pending" orders (single resource only). |
Customers | ​✅​ | ​ | ​ | ​ | ​ |
Customer subscriptions | ​✅​ | ​ | ​ | ​ | ​ |
Customer password resets | ​✅​ | ​✅​ | ​✅​ | ​ | Single resource only. |
Sales channel applications can authenticate a customer through the password flow. The access tokens that they get include the sum of the client permissions plus the ones below.
​ | Create | Read | Update | Delete | Restrictions |
Customers | ​ | ​✅​ | ​✅​ | ​✅​ | The customer must be the authenticated resource owner. |
Customer addresses | ​✅​ | ​✅​ | ​✅​ | ​✅​ | The customer must be the authenticated resource owner. |
Customer subscriptions | ​✅​ | ​✅​ | ​✅​ | ​✅​ | The customer must be the authenticated resource owner. |
Orders | ​✅​ | ​✅​ | ​✅​ | ​ | The customer must be the authenticated resource owner. |
Parcels | ​✅​ | ​ | ​ | ​ | The parcels must belong to one of the customer's orders. |
An access token obtained through a refresh_token inherit the same set of permissions of the one that expired.
Integration applications support the client_credentials grant type. The access tokens that they get include the set of permissions of their role.
Webapp applications support authorization_code and refresh_token grant types. They don't bring any grants to the access tokens, and get the set of permissions of to the authenticated user's role. Access tokens obtained through a refresh_token inherit the same set of permissions of the one that expired.
Other application types (such as Zapier, Contentful, DatoCMS etc.) have more straightforward authorization rules and get the right amount of permissions that are required by the relevant tool.
Commerce Layer Zapier app is currently private. Feel free to accept this invitation and start building your zaps!
