Dolibarr exposes ERP and CRM data through a REST API. An API token is associated with a user, and that user's permissions determine which modules and records the request can reach. Treating the token as a generic application secret misses the fact that each integration may be operating with a named person's rights.
The token points to a user
Dolibarr's REST API documentation instructs operators to paste the API token for the user who will call the service. The permissions documentation describes module permissions stored in user and group relationships. The effective API authority is therefore the result of the user, the groups, the module rights, and the object-level behavior of the endpoint.
Create a dedicated integration user for each application or business function. Do not issue a token for a general administrator because setup is easier. Grant only the permissions the endpoint sequence needs, then test denied actions as well as successful ones.
Review groups and defaults
Group membership can make an individual token broader than its owner understands. Review inherited permissions, default permissions assigned to new users, and any group that was created for a temporary project.
Dolibarr's security settings documentation notes that default permissions apply to newly created users and do not retroactively change existing users. That makes defaults an onboarding control, not a repair mechanism. Existing integration users need explicit review.
What the ZoomEye observation shows
This measurement used count-only queries with sub_type=all, page 1, and page size 1. app="Dolibarr" returned 812, title="Dolibarr" returned 4,238, and http.body="Dolibarr" returned 1,012,186.
The body count is far too broad for an installed-base claim. It can include documentation, integrations, and unrelated references. The application fingerprint is smaller and more specific, while the title count captures pages that expose the product name in HTML.
Use these counts to prioritize a comparison with DNS, certificate, and cloud inventory. Do not attempt to authenticate or enumerate records on an unknown Dolibarr instance.
API-specific checks
Record the endpoint family, required module permission, token owner, token storage, and last use. Test list, read, create, update, and delete operations with the integration user. Confirm that a denied module returns an authorization failure rather than an empty result that the application might interpret as success.
Review webhook and outbound integration credentials separately. A compromised API token may allow the attacker to read business records, but a webhook secret may let them forge events into another system.
Rotation and offboarding
When a staff member leaves, do not only disable the human account. Find every API token issued to that account and determine whether an integration depends on it. Move the integration to a dedicated user before revoking the token.
Rotate tokens on a schedule and after suspected exposure. Update the secret store first, verify the new token, then revoke the old one. Check logs for both users during the transition.
A Dolibarr token is a delegated user identity. The useful inventory is not a list of strings; it is a list of users, groups, permissions, and business records that each string can reach.