Choose the right scopes
Scopes describe the capabilities a token can use. A capability must be granted to your application and requested when obtaining the token. A broad grant on the client does not make a narrower token broader.
Read and search are different
| Scope example | Intended capability |
|---|---|
api | Broad public-API operation access, subject to record permissions |
api.read | Read resources by identifier across resource types |
api.search | Search resource collections |
api.contacts | Contact operations |
api.contacts.read | Read contacts by identifier |
api.contacts.search | Search contacts |
api.leads | Supported lead operations |
api.marketing | Marketing consent operations |
These are capability examples, not an invitation to request every scope. Use the scopes issued for your application and ask LMG for the smallest set that supports your workflow.
How the hierarchy works
The implementation checks resource and action parts. For example, api.contacts can satisfy a contact read requirement, while api.contacts.read cannot satisfy a contact create requirement. Resource-less scopes such as api.read apply to the corresponding action across resources.
A token that can read /jsonapi/contacts/{id} may still receive 403 when querying /jsonapi/contacts. Collection search has its own requirement.
Scope checks are only one layer. The application must also have access to the resource, and write operations need valid adviser context. Beta access adds an availability check without replacing normal authorisation.
Diagnose a scope problem
Check the scopes requested from the token endpoint, then the operation being attempted. If access was recently changed, obtain a new token. If the scope is correct, inspect the data access rules and UserId rather than requesting broader access by default.