d.velop documents

Getting an API key

1. In d.velop cloud open Konfiguration → API-Schlüssel (or, on premises, the identityprovider app) and create an API key for a technical user.
2. Give that user read rights on the repositories the agent should reach. d.velop applies its permission model per document, so a restricted user quietly sees a smaller repository.
3. Set DVELOP_URL to your tenant root — https://<tenant>.d-velop.cloud for cloud, or your own host on premises — and DVELOP_API_KEY to the key.

The Authorization header is Bearer <apikey>, with the API key used directly as the bearer token. d.velop's API keys are long-lived; rotate them the way you would rotate a password.

Repository ids come first. d.velop can host several repositories in one tenant and every document operation is scoped to one. Call d_velop_list_repositories and keep the id — it is an opaque string, not a number.

Search is HAL-shaped. Responses embed results under _embedded.repositories / _embedded.results and carry _links for paging. Follow _links.next.href rather than computing an offset; d.velop's cursors are not guaranteed to be stable integers.

Source ids narrow a search. A repository can expose several sources (index definitions); sourceid restricts a search to one of them, which is usually what makes a fuzzy search precise.

Unverified. The paths and field names below follow the vendor's published documentation and have not been exercised against a live tenant — d.velop does not offer a public sandbox. Treat a 404 as a docs-versus-reality gap and check the developer portal before concluding that the credential is wrong. If you run this against a real system, a correction to the adapter JSON is genuinely welcome.

Read-only by design: no upload, no property change. A DMS is the audit trail, and an agent should not be able to edit it by accident.