Document Service API
The Document Service API is built on top of the Query Engine API and is used to perform CRUD (create, retrieve, update, and delete) operations on documents .
The Document Service API also supports counting documents and, if Draft & Publish is enabled on the content-type, performing Strapi-specific operations such as publishing, unpublishing, and discarding drafts.
In Strapi 5, documents are uniquely identified by their documentId at the API level.
The Document Service API replaces the Entity Service API used in Strapi v4 (see Strapi v4 documentation).
Additional information on how to migrate from the Entity Service API to the Document Service API can be found in the migration reference.
Relations can also be connected, disconnected, and set through the Document Service API, just like with the REST API (see the REST API relations documentation for examples).
The Document Service is a data-access layer: it interacts with the database and is not aware of user permissions or field visibility. Results may include private fields, passwords, and restricted relations.
The built-in REST and GraphQL APIs automatically sanitize responses before sending them to the client. But if you build custom controllers or plugin routes that call Document Service methods directly, you must sanitize the output yourself before returning it. Use strapi.contentAPI.sanitize.output() in your controller (see Sanitization and validation when building custom controllers for details and code examples).
Configuration
The documents.strictParams option enables strict validation of parameters passed to Document Service methods such as findMany and findOne. Configure it in the API configuration file (./config/api.js or ./config/api.ts). See the API configuration table for details on documents.strictParams.
Document objects
Document methods return a document object or a list of document objects, which represent a version of a content entry grouped under a stable documentId. Returned objects typically include:
documentId: Persistent identifier for the entry across locales and draft/published versions.id: Database identifier for the specific locale/version record.- model fields: All fields defined in the content-type schema. Relations, components, and dynamic zones are not populated unless you opt in with
populate(see Populating fields) or limit fields withfields(see Selecting fields). - metadata:
publishedAt,createdAt,updatedAt, andcreatedBy/updatedBywhen available.
Optionally, document objects can also include a status and locale property if Draft & Publish and Internationalization are enabled for the content-type.