Ir al contenido principal
DocumentMS
Solicitar una demoPrueba gratuita
Español

Developer docs

Document management API documentation

The DocumentMS REST API covers documents, folders, metadata, versions, permissions, workflows, signature requests and audit events. Webhooks push the same events outward. This section documents authentication, pagination, rate limits and the error contract, with a worked example per endpoint group.

The reference below covers the shipped API. Where a section is still being written it is listed as such further down the page rather than left as a dead link.
Solicitar una demoVer precios

Documentation sections

What a developer needs before committing to a dependency.

  • REST API

    Documents, folders, metadata, versions, permissions, workflow instances, signature requests and audit events. Scoped API keys, consistent pagination, a documented error contract.

  • Webhooks

    Event catalogue and payload signing. At-least-once delivery, so handlers must be idempotent — the event identifier is there for exactly that.

  • Single sign-on

    OIDC setup for Microsoft Entra ID, Okta and Google Workspace, including group-to-role mapping and what happens on deprovisioning.

  • Storage backends

    Configuring Amazon S3 or Azure Blob Storage in your own account, including the IAM policy scope and how retention interacts with object lock.

What still needs writing

Listed rather than hidden, because a documentation site that looks complete and is not wastes more of a developer’s time than one that is honest about its gaps.
  • An OpenAPI specification you can generate a client from, rather than a reference you read and transcribe by hand
  • Worked examples in curl, TypeScript and Python for the paths most integrations actually take
  • A webhook event catalogue with example payloads and a signature verification recipe in each language
  • A migration cookbook covering bulk import from SharePoint, network shares and the common legacy systems
  • A sandbox tenant with seeded data, so an integration can be built and tested before a contract exists

Design principles for this API

The contract matters more than the surface area. An API that changes shape between releases costs more to depend on than one with fewer endpoints and a stable interface, so breaking changes are versioned rather than shipped in place.

Events are pushed rather than polled. If your system needs to know when an approval completes, subscribe to a webhook — polling a collection endpoint on a timer is both slower and considerably more expensive in rate limit.

Keys are scoped, not inherited. An API key carries the permissions granted at creation and does not act as a user, which means an over-scoped key is the most common integration security mistake and the easiest to avoid.

Última revisión: 2026-09-01

Building an integration?

Tell us what you are connecting and we will tell you plainly whether the API covers it today.
Solicitar una demoPrueba gratuita