Licenses and Permissions

Whether a request is allowed depends on two independent questions:

1. Is the firm authorized to use the interface at all — and with whom? That's the license.
2. What is the calling user allowed to do? That's the functional permissions.

If the first is missing, the response is 403 LICENSE_MISSING. If the second is missing, 403 INSUFFICIENT_SCOPE.

⚠️ Your contract is what matters. This page describes the license variants as they are typically sold. What your firm is actually authorized to use is defined in your contractual agreement with STP — and that may differ: in scope, in terms, or in individual conditions. Where there are discrepancies, the contract takes precedence over this documentation. If in doubt, contact your STP representative.

The Two License Variants

A firm may hold both. In that case, the full license applies — it is the higher-tier option and covers the request regardless.

The Difference in Practice

• With a full license, the firm can register applications in its own user management. An in-house development or automation tool can be given its own access without any setup required on STP's end.
• With a partner-bound license, this is not possible. Access is tied to the login of the specific partner product. If another application attempts access, the interface responds with 403 CLIENT_NOT_LICENSED.

What a Request Requires: Always Two Permission Scopes

Every request is checked against two types of permission scopes in the token:

A read operation, for example, requires both dms.cloud.api.standalone and dms.cloud.api.documents.read.

Which capability scope applies to which endpoint is listed in Endpoint Overview.

The Order of Checks

The interface checks in the following order, and the first unmet condition determines the response:

Steps 1 through 4 run in the cloud and do not require a round trip to the firm. Step 5 takes place within the firm's document management system.

Step 5 is the exception: the document management system does not distinguish in its response between "does not exist" and "this user is not permitted to see it." A denial based on access rights therefore does not reach the interface as a distinct message and is reported as 404 NOT_FOUND. An unexpected 404 should therefore prompt a review of permissions as well — see Error Codes.

Why a Token May Contain Fewer Scopes Than Expected

What actually ends up in the token is the intersection of three lists:

Scopes in token = what the application is allowed to request
                ∩ what the firm's license provides
                ∩ what the user's roles provide

This leads to three observations that commonly come up in practice:

• A scope that the application is not permitted to request will never appear in the token — regardless of how well-licensed the firm is.
• A role is only an offer. Roles carry both license scopes within them; which one actually ends up in the token is determined solely by the firm's license.
• A firm with a full license will receive only the full license scope — even when calling via a partner product — and will be treated as a full license user.

Roles for the Acting Account

Roles are assigned via groups; a default group for each role is available in every tenant. Details and instructions for creating custom groups can be found in Roles and Groups.

There are no partner-specific roles. The firm's administrator uses the same roles regardless of which license the firm holds — which license scope ends up in the token is determined solely by the license.

Questions About Scope

Whether a specific use case is covered by your license cannot be definitively answered here — the answer is in your contract. This page helps with technical classification: it explains why a request is rejected and which factor is responsible. Whether that factor can be adjusted for your firm is a contractual matter.

Further Reading

• Getting Started
• Error Codes