Skip to content

Build on the platform

Everything Packt does with content — ingesting a manuscript, resolving its rights, composing a Product, shipping it to a Channel — is available to you through the same interfaces Packt's own applications use. There are no private backdoors and no internal-only shortcuts: Packt dogfoods its own platform, so anything a Packt app can do, your integration can do too. This section is the entry point for building on it.

The single public entrance is the Public API: one HTTPS REST/JSON interface at https://api.packtpub.services, versioned under /v0/. It fronts the platform's internal services — read and write content in the Content Lake, resolve rights, run search — and every request carries a WorkOS-issued token that identifies who is asking and which Tenant they belong to. One token acts for exactly one tenant, so your integration never has to juggle tenant isolation itself.

Because the platform is event-driven, you can also build the other way round: instead of asking "has anything changed?", you let the platform tell you. When a Resource is created, a Work's rights change, or a Product is published, the platform emits an event — and you can receive it as a webhook, or route it into Zapier, n8n, or your own queue. Reading and reacting are the two halves of most integrations.

This page lays out the four ways to build, helps you pick the right one for what you are trying to do, and points you at the page where each one is specified in full. If you are in a hurry, jump to the chooser table below.

The four ways to build

There are four routes onto the platform. They are not alternatives so much as layers — most real integrations use two or three together (the API to read and write, events to stay in sync, an SDK to make both pleasant).

  1. The REST Public API. The foundation. A versioned HTTP/JSON contract for reading and writing content, resolving rights, and running search. Everything else on this list is either built on it or notifies you about it. Start at Public API.

  2. Events and webhooks. The platform announces change — a Resource created, a Work's rights changed, a Product published — as events. Subscribe to react in near real time instead of polling. Events leave the platform wrapped in a CloudEvents envelope, so any standard webhook or automation tool can consume them. Start at Events & webhooks.

  3. Official SDKs. Typed client libraries for JavaScript/TypeScript, Go, Python, and PHP, generated from the API's OpenAPI specification so they never drift from the contract. They handle tokens, retries, idempotency, and pagination for you. Start at Public API → SDKs.

  4. No-code and AI tools. You do not have to write code at all. The REST API and the CloudEvents webhooks are designed so that Zapier, n8n, Make, and LLM/agent tools can drive the platform directly — and so that AI app builders like Lovable or Replit can scaffold a UI against it in minutes. Start at No-code & AI tools.

Which way should I build?

Find the row that matches your goal and start where it points. Most integrations end up combining a couple of these.

I want to… Start at Why
Read or write content, resolve rights, run search Public API The REST surface is the direct, synchronous way to query and mutate the estate.
React when something changes (a Resource, a Work's rights, a Product) Events & webhooks Subscribe once and the platform pushes changes to you — no polling.
Build a real integration in JS/TS, Go, Python, or PHP Official SDKs Typed clients handle auth, retries, idempotency, and pagination for you.
Automate a workflow without writing code No-code & AI tools Zapier, n8n, and Make speak the REST API and CloudEvents webhooks natively.
Prototype a UI fast with an AI app builder No-code & AI tools Point Lovable or Replit at the OpenAPI spec and scaffold against it.
Point an LLM or agent at the platform No-code & AI tools The API is designed to be called by tools; rights are enforced server-side on every call.
Understand how to authenticate any of the above Authentication One token model — WorkOS-issued JWTs — covers humans, apps, and machines.
Copy a working end-to-end example Recipes Task-first walkthroughs stitch the API, events, and auth together.

Start with authentication either way

Whichever route you take, the first thing you need is a token. The Authentication page covers the three caller flows — a person signing in, a third-party app acting for a user, and a service acting as itself — all of which produce the same kind of token. There are no API keys and no tenant header; the tenant is carried inside the token.

Where the Public API sits

The Public API is the platform's only public front door. A client — your browser app, your server, a no-code tool, an SDK — talks HTTPS to the Cloudflare edge, which terminates TLS and provides the platform cache and web-application firewall. The edge forwards to the Public API service, which validates the token and translates each REST call into one or more calls to the internal services that actually hold the data. The client never talks to those internal services directly.

flowchart LR
    subgraph client [Your side]
        APP["Your app · SDK<br/>no-code tool · agent"]
    end
    subgraph edge [Packt edge]
        CF["Cloudflare<br/>TLS · cache · WAF"]
    end
    subgraph platform [Packt Platform]
        API["Public API<br/>validate token · translate"]
        CL["Content Lake"]
        RR["Contracts &amp; Rights"]
        SR["Search"]
    end
    APP -->|"HTTPS + Bearer token"| CF
    CF --> API
    API -->|internal| CL
    API -->|internal| RR
    API -->|internal| SR

Two things about this shape matter when you build:

  • One token, one tenant. Every request carries a WorkOS-issued token in the Authorization: Bearer … header. The Tenant is read from the token's tenant_id claim — you never send a tenant header, and one token can only ever act for the tenant it was issued for. Scopes travel in the same token. See Authentication.

  • The edge is not the trust boundary. Passing the Public API proves nothing on its own; the internal services re-validate every request. The API's job is translation and caching, not gatekeeping — so rights are enforced deep in the platform, on every call, no matter which of the four routes you came in through.

The launch surface is the Content Lake

At launch, /v0/ covers the Content Lake: Resources, Works, Sources, Activities, ContentUnits, access grants, snapshot versions, search, and blob access — with resolved rights carried inline on every read. Product Management and Distribution routes are later additions under the same /v0/ prefix. The full route catalogue is on the Public API page.

A first request

Reading a single Resource is one authenticated GET. The fields mask keeps the response lean; rights returns the resolved usage view so you can see what may be done with the content before you use it.

GET /v0/content-lake/resources/res_ml_go_ch3?fields=id,title,rights HTTP/1.1
Host: api.packtpub.services
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Accept: application/json

The same read is a couple of lines through an SDK, which supplies the base URL, attaches the token, and returns a typed object:

import { PacktClient } from '@packt/api-client';

const packt = new PacktClient({ token: process.env.PACKT_TOKEN });

const resource = await packt.contentLake.resources.get('res_ml_go_ch3', {
  fields: ['id', 'title', 'rights'],
});

To receive the other direction — a notification when that Resource changes — you subscribe to an event rather than polling this endpoint. Events are named platform.<service>.<entity>.v1.<verb>, so a new Resource arrives as platform.content-lake.resource.v1.created and a rights change as platform.content-lake.work.v1.rights_changed. See Events & webhooks for the full catalogue and how to subscribe.

Where to go next

  • Public API — the REST contract in full: conventions, field masks, pagination, idempotency, errors, caching, the route catalogue, content negotiation, and the official SDKs.
  • Authentication — the token model and the three caller flows; read this before your first real call.
  • Events & webhooks — the event catalogue, the CloudEvents envelope at the egress, and how to subscribe.
  • No-code & AI tools — driving the platform from Zapier, n8n, Make, LLM agents, and AI app builders.
  • Recipes — task-first walkthroughs that combine the API, events, and auth into working examples.