Skip to main content
Use the publive-cms-sdk package when you want a typed client for Publive content delivery and selected CMS utilities.
Keep your Publive credentials on the server. Do not initialize this SDK in client-side code.

Overview

This page gives you a practical view of the SDK surface, the main methods available in each namespace, and the places where the existing API reference is still the better source for endpoint-level detail.

Install the package

Use Node.js 18 or later so you have a supported fetch runtime by default.

Initialize the SDK

Configuration

Core services

The Publive class exposes five service areas:

Where the SDK fits

The SDK works well as a server-side client for common Publive workflows. It provides typed helpers for content retrieval, layout data, slots, forms, and publisher metadata, while also handling authentication headers, retries, and timeouts in one place. For endpoint-by-endpoint behavior, request and response details, or flows outside the exported namespaces, the API reference remains the better companion.

SDK surface

The tables below summarize the current callable surface exposed by the SDK.

sdk.content

sdk.utils

Other namespaces

Fetch content

Work with posts

Available post helpers:
  • fetchById(id)
  • fetchBySlug(slug)
  • fetchByLegacyURL(legacyUrl)
  • fetchList(options)
  • fetchFeaturedPosts(options)
  • fetchPostByCategory(categoryId, options)
  • fetchPostByTag(tagId, options)
  • fetchPostByAuthor(contributorId, options)
  • fetchPostByCollectionSlug(collectionSlug, options)

Work with categories, tags, and authors

Each content service supports:
  • fetchById(id)
  • fetchBySlug(slug)
  • fetchList(options)

Identify a URL or slug

Use identify when you need to resolve a slug or legacy URL to its Publive content type. For the HTTP endpoint details, see [Identify content](/dxp/api-reference/content-delivery/identify- content).
identify() returns metadata about the resolved URL, including type, url, status_code, and optional content.

Fetch layout and utility data

Forms are available through the management client:

Fetch publisher metadata

This returns publisher-level configuration and metadata for the current credentials.

Use low-level clients

The low-level delivery and management clients are useful when you need a request that does not yet have a dedicated helper.
They are most useful when:
  • the SDK already supports the authentication and environment handling you need
  • the helper method you want does not exist yet
  • you already know the exact endpoint from the API reference
In most cases, the higher-level namespaces are easier to work with because they already encode the common paths and usage patterns.

Request options

Most SDK methods accept a RequestOptions object. Example:

Use the media URL helper

The package also exports a lightweight helper namespace for image URL transforms.
Supported presets include small, medium, default, large, xlarge, portrait, and custom.

Exported enums and helpers

The package also exports constants, enums, types, and error classes that are useful when building app logic. Common exports include:
  • PostCollectionSlug
  • PostType
  • RSSPostType
  • CDSAdvancedFilter
  • PLException
  • PLAPIException
  • publive.utils.lib.convertMediaURL

Handle errors

The SDK throws typed API errors for failed delivery requests.

Behavior notes

These details are easy to miss and are useful to keep in mind while building:
  • The SDK is designed for server-side use because it requires apiKey and apiSecret.
  • sdk.utils.form uses the CMS management client under the hood, not the delivery client.
  • sdk.delivery and sdk.management do not handle failed responses in exactly the same way.
  • version in RequestOptions rewrites the request path to include an API version segment.
  • environment changes the base host used by the SDK: production, beta, and development do not hit the same backend.
  • retry and timeout can be overridden per request instead of only at initialization time.

Map SDK methods to existing docs

This table points to the existing API docs when you want more endpoint-level detail without repeating that material here.

Example: server route

This pattern works well in a Next.js route handler or any server-only endpoint.

Content Delivery API

See the underlying delivery endpoints

Content Management API

See CMS endpoints used by form helpers

Next.js integration

Use the SDK in a server-rendered frontend

Decoupled frontend

Build a custom frontend on top of Publive
Last modified on July 21, 2026