For a law firm to connect a partner product to their document management system, three things are required. This guide explains what they are, who takes care of each one, and what the firm itself needs to decide.
Looking to develop against the API yourself? Then Connecting Your Own Application is the right place to start — it covers client registration, the authentication flow, and your first API call.
Step one: Check the prerequisites
| What | Who handles it |
|---|---|
| The firm holds a license for the Documents Partner API | STP |
| The connector is installed, signed in, and connected to document management | The firm, supported by STP Service |
| The relevant user accounts have the appropriate role | The firm's administrator |
The first two are taken care of before you need to do anything. The third is what this guide is all about.
Details on which license tier allows what can be found in Licenses and Permissions. For connector installation, see Connector Installation Step by Step.
Step two: Define the user accounts
The partner application does not act as an "application" — it acts on behalf of a user within the tenant. That user's permissions in the document management system determine every individual access request. There are two models for this, and the choice should be made at the very start of the integration:
| Model | How it works | When it fits |
|---|---|---|
| Delegated user (recommended) | Each user signs in to the partner application with their own STP account. The application interacts with the API under exactly that account. | Whenever people are actively working with the partner application |
| Technical account | A single account belongs to the partner application. All access runs under this account, regardless of who is operating the application. | Automated workflows with no human actor — batch imports, background services |
Why the delegated user is the better choice
The document management system's permissions then apply exactly as the firm has configured them: anyone who isn't allowed to see a case file in document management won't be able to see it through the partner application either. And the case file history records who took each action.
A technical account removes both of these guarantees. It requires the combined permissions of every user who might need access — meaning more than any individual should have — and the same account appears in the history for every action. That's acceptable for a background service, but not for an application used by real people.
What the firm's administrator sets up
In both models, the relevant account is assigned one of two roles:
| Display name | Technical name | Effect |
|---|---|---|
| Documents Partner API User (read + write documents via the HTTP edge) | DmsCloudApi.User |
Read and store documents |
| Documents Partner API Reader (list + download only) | DmsCloudApi.User.Reader |
Read documents only |
Roles are assigned through a group. A suitable default group for each role already exists in every tenant — simply add the account to it. If you want to customize the roles, you can create your own groups. Both options are described in Roles and Groups.
Two things are important here:
- Document management permissions apply on top of this. The role opens up the API; which case files, folders, and documents the account can actually view and modify is still governed by the local document management system's permission settings for that specific user.
-
The account must be known to the document management system. The cloud login and the local
document management system are linked via a user identifier. If this link is missing, every call that touches the
document management system will fail — with
403 MISSING_USER_IDENTITY.
Step three: Connect the partner product
How the connection is established depends on the partner product — in most cases, you simply enter the tenant name and sign in once.
The tenant name is the first part of your STP Cloud login URL:
https://<tenant>.stp-cloud.de
^^^^^^^^^It's the same value the administrator enters when installing the connector. If the partner product asks for it and no one has it on hand: it can be found in the firm's access credentials.
Everything else — sign-in, permissions, API calls — is handled by the partner product.
Step four: Verify that it works
The first access from the partner product also serves as the test. If it succeeds, all three prerequisites are met.
If it doesn't, the cause is almost always one of the following:
| What the user sees | Likely cause | Who can help |
|---|---|---|
| A message about missing permissions | The account isn't in an appropriate group — or the default group is missing from the tenant | The firm's administrator — see Roles and Groups |
| A message about a missing license | The license is missing or doesn't match the product | STP |
| No case files are found, even though they exist | The account's permissions within the document management system — these apply in addition | The firm's administrator |
| No connection at all, timeouts | The connector isn't running or can't reach the cloud | STP Service |
Your partner product may display these situations differently. If it shows an error code or a support code in the format
STP-DMS-…, include it when contacting support — it allows STP to locate the specific call.
Further reading
- Roles and Groups — default groups, custom groups, and what to do when a permission isn't taking effect
- Licenses and Permissions
- Connecting Your Own Application — if you're developing yourself