API Tokens

API tokens let external tools and integrations sign in to DocMgt's REST API and MCP server without storing a real person's username and password. A token is a single secret value — it starts with dmapi_ — that you generate once and paste into an integration's configuration in place of a password. The integration then sends the token on every request and DocMgt treats it as a sign-in for the user the token was issued to. Tokens are the recommended credential for any automation: they can be revoked at any time without changing anyone's login, they can be set to expire, and the real password never leaves the person who owns it. End users signing in to the web application are unaffected — they keep using their username, password, and any multi-factor or single sign-on exactly as before; tokens are only for API and integration access.


Who can manage tokens

Only administrators can create, view, or revoke API tokens, and they do so on behalf of any user. Regular users cannot mint their own tokens. You manage tokens under Admin, in the Security and Access group, on the API Tokens screen.


How a token relates to a user and its rights

Every token is issued for one specific DocMgt user and inherits exactly that user's rights — the same record type access, field-level rights, document rights, and search rights that apply to that user in the web application apply identically to anything using the token. A token can never do more than its user can. Because of this, the best practice is to create a dedicated DocMgt user for each integration and grant that user only the access it actually needs, leave administrator rights off, and issue the token against that locked-down account rather than a real person's login. Every action taken with the token is attributed to that user in the normal DocMgt logs, so you keep a complete audit trail.


Generating a token

On the API Tokens screen, click New Token. Choose the user the token will act as, give the token a descriptive name so you can recognize it later (for example "Importer on server X" or "Nightly billing export"), and choose when it should expire. You can let it expire in 90 days, which is the recommended default, pick a specific expiration date, or choose never to expire. A token that never expires is convenient but is a standing credential, so prefer a dated expiry and rotate it. When you click Generate, DocMgt shows you the new token one time.


Copy the token immediately — it is shown only once

For security, DocMgt stores only a one-way fingerprint of the token, never the token itself, so the full value can be shown only at the moment it is created. Copy it from the confirmation dialog right away and paste it into your integration's configuration. Once you close that dialog the token cannot be retrieved again. If you lose it, you do not recover it — you revoke the old token and generate a new one.


Using a token in an integration

A token is sent in the request's Authorization header using the Bearer scheme, with the token value exactly as issued and no encoding step: Authorization: Bearer dmapi_…. This is simpler than Basic authentication, which requires encoding a username and password together. The same token works for both the DocMgt REST API and the MCP server, since they share the same sign-in. Most tools accept the token directly in a field; where a tool only lets you supply a raw header, paste the whole Authorization: Bearer dmapi_… line.


Reviewing and revoking tokens

The API Tokens screen lists every token with the user it belongs to, its name, its expiration, and when it was last used, so you can spot tokens that are unused or about to expire. To turn a token off, revoke it. Revoking takes effect immediately and permanently: any integration still using that token stops working at once, and the action cannot be undone. Revoke a token whenever it is no longer needed, when it may have been exposed, or when you are rotating to a new one. Expired and revoked tokens remain in the list for reference but can never authenticate again.


Limits

Each user can have up to ten active (non-revoked) tokens at a time. If you reach that limit, revoke a token you no longer use before generating another. This keeps the list manageable and limits how many live credentials exist for any one account.


TIPS

  1. Issue each token against a dedicated, locked-down DocMgt user, not a real person's login — the token inherits exactly that user's rights and every action is attributed to it.
  2. Give every token a clear name that says where it is used, so you can recognize and revoke the right one later.
  3. Prefer a dated expiry over "never," and rotate long-lived tokens periodically by generating a new one and revoking the old.
  4. Copy the token when it is shown — it cannot be retrieved afterward; if lost, revoke and regenerate.
  5. Revoke immediately if a token may have been exposed; revocation is instant.


NOTE: An API token is a password replacement for API and integration access only. It grants exactly the rights of the user it is issued for, so scope that user carefully. Keep tokens secret — anyone holding a token can act as that user until the token expires or is revoked.


See also