Public API Introduction

The Livingdocs Public API is a REST API for integrating with Livingdocs. All endpoints use JSON, bearer token authentication, and date-based versioning in the URL path (e.g. /api/2026-01/). See Authentication and API Versioning for details.

Reading Publications

The most common use case is fetching published content for rendering on a website or app.

  • Latest Publications — List or export published documents, with filtering by content type, date range, or document id
  • Search Publications — Full-text and metadata search across published documents
  • Latest Publication — Fetch a single publication by document id
  • Composition API — Fetch a publication with resolved includes and resolved linked content, ready for rendering
  • Publication Events — Track publish, unpublish, and update events for cache invalidation or synchronization with external systems

See the Document Object reference for a detailed description of all fields returned by these endpoints.

Reading Drafts

For workflow or preview integrations where external systems need access to unpublished documents.

Document Commands

The Command API allows external systems to manipulate documents — update content and metadata, or trigger publications programmatically.

Delivery

Track and report delivery status for documents that use delivery configurations.

Imports

The Import API covers initial imports of large datasets as well as continuous imports for ongoing synchronization. It supports both documents and media library assets.

Imports are event-based and built for large volumes. Import jobs are batched and processed by worker instances of the Livingdocs server to minimise impact on the running system. Because of this architecture, processing time depends on the provisioning of worker resources. Administrators can monitor queue sizes and state in the Livingdocs Editor.

For large initial imports, coordinate with Livingdocs in advance. Even though the import system is designed for high throughput, the database and infrastructure may need to be scaled to handle the load effectively.

Incoming References

These endpoints answer the question: "What links to this resource?" This is useful for cache invalidation when linked content changes, or for checking whether a media asset is still in use before archiving it.

There are four endpoints covering two dimensions — the resource you're querying (row) and the type of reference you're looking for (column):

TargetReferenced by DocumentsReferenced by Media Library Entries
DocumentIncoming Publication ReferencesIncoming Media References
Media Library EntryIncoming Publication ReferencesIncoming Media References

See the References Object reference for the structure of reference entries and their location types.

Media Library

Manage media library entries directly. Unlike documents, media library entries do not have a publish mechanism — all changes take effect immediately.

See the Media Library Entry Object reference for a detailed description of all fields.

Project Configuration

Read the full project configuration via API, including content types, design settings, and feature configurations.

Integrations

  • Retresco — Re-enrich documents with Retresco metadata

Other Endpoints

  • Sitemaps — Generate sitemaps for published content
  • Health — Health check endpoint for monitoring (Livingdocs already monitors this for managed service customers)
  • Menus — Read menu structures

The Document Lists, Document Categories, and Routing endpoints are legacy and no longer recommended for new integrations.

OpenAPI Specification

Every API version has a downloadable OpenAPI 3.1 specification. You can use it with tools like Postman, Insomnia, or Bruno to explore and test endpoints.

Use the Download OpenAPI spec link below the version selector in the sidebar to get the spec for the currently selected version.

⌘ K to search