In both cases, the principle of least privilege applies, meaning you should request only the scopes your app actually needs.
Anatomy of a Scope
Every scope follows the patternresource.permission.
Permissions do not include each other.
write does not imply read, and print does not imply either. If your app needs to read items, modify them, and generate printed documents, declare all three: items.read, items.write, items.print.Available Scopes
The table below is generated from the latest cloud OpenAPI spec. Any value outside this list is rejected at registration in both Cloud (manifest validation) and OnPremise (registration POST).Sales
Inventory and Fulfilment
Finance
Procurement
System
Other
Cloud Scopes
For Cloud, you declare API scopes in yourapp.json under capabilities.erp.api.scopes. These scopes determine which JTL-Wawi API endpoints your app can call.
Declaring Scopes in the Manifest
resource.permission:
Requesting
write access does not automatically include read. If your app needs to both read and modify items, declare both items.read and items.write.Capability-level Permissions
Beyond API scopes, Cloud Apps can enforce granular permissions on individual capabilities like panels. This lets you scope specific UI surfaces to a smaller subset of resources than the app as a whole.Panel Permissions
UserequiredScopes on a panel definition to control resource access:
requiredScopes accepts the same scopes listed above.
OnPremise Scopes
For OnPremise integrations, scopes are declared during app registration via the REST API. You include them in themandatoryApiScopes and optionalApiScopes arrays of the registration request.
Registering with Scopes
The example below registers an app that requires four scopes and optionally uses one more.Fetching Registration Status and Granted Scopes
After registering, the API returns aregistrationId. Poll the registration status endpoint with this ID to retrieve your API key and confirm which scopes were granted:
grantedScopes array tells you exactly which permissions your app received. If any of your optionalApiScopes were not granted, they will be absent from this array. Your app should check grantedScopes and adapt its functionality accordingly.
Mandatory vs. Optional Scopes
Use mandatory scopes for core functionality and optional scopes for enhanced features that can degrade without breaking core functionality.
Updating Scopes After Registration
- Cloud
- OnPremise
Cloud Apps support updating scopes by modifying your
app.json. Update the capabilities.erp.api.scopes array, then re-submit the updated manifest through the Partner Portal.Best Practices
Request minimal scopes. Only declare scopes your app actually uses. Separate read, write, and print. If your app only displays data, requestread only. Add write when your app modifies resources. Add print only when you need to print.
Avoid system.all. Use granular scopes wherever possible.
Use optional scopes for progressive features (OnPremise). If your app has optional features that need extra permissions, put those in optionalApiScopes so the core app still works without them.
Document your scopes for merchants. In your App Store listing and support docs, explain why your app needs each scope. Transparency builds trust.
Check scopes at runtime. Before making API calls that require specific permissions, verify your app has the necessary scope. Handle 403 Forbidden responses by showing clear messages.
What’s Next
OAuth 2.0 Flow
Understand how tokens and scopes work together in the authentication flow.
API Keys & Tokens
Reference for all credential types across Cloud, OnPremise, and SCX.
Error Handling
Handle permission errors and scope-related 403 responses.
App Manifest Reference
Full app.json schema including all capability fields.