Events & webhooks

The platform is event-driven: whenever something meaningful happens — a Resource is written, a Contract changes, a Product is published — the service responsible announces it as an event. Other services and your own integrations react to those announcements instead of polling an API on a timer. This page is the guide to consuming them: what the events are called, which ones you are allowed to build on, how they are delivered, and how they reach no-code tools such as Zapier and n8n as webhooks.

Events come in three tiers. Platform events (platform.*) are a stable contract: any platform service may subscribe, and their payloads only change in backwards-compatible ways within a major version. Internal events (internal.*) are a private implementation detail of the service that emits them — they chain that service's own workflows, can change without notice, and are never something you subscribe to. External events (packt.*) are how the platform reaches tools outside it — Zapier, n8n, webhook endpoints you host — through the Eventing service's curated catalogue, delivered as CloudEvents (see Webhooks and no-code tools). Inside the platform, everything you can integrate with is on the platform tier.

Each publishing service owns a platform bus named platform-<service> (for example platform-content-lake). You attach a target — an AWS Lambda, an SQS queue, another bus — to the events you care about, filtered by name or pattern. Producers never know who is listening, so a contract change quietly ripples out to rights across the estate without anyone wiring services together by hand.

A quick worked example: an author's manuscript is ingested, and the Content Lake publishes platform.content-lake.resource.v1.created for each chapter. Your integration is subscribed, so it registers the new content in a downstream catalogue and pings an editor in Slack — all without the Content Lake knowing your integration exists.

How events flow

Internally the platform speaks Amazon EventBridge. Events that reach tools outside the platform — a webhook, Zapier, n8n — are a separate, curated set: the Eventing service watches the platform buses and publishes external events as CloudEvents at the egress. An external event has its own name (packt.*) and its own payload, designed for workflow builders — it is not the internal event re-wrapped. Everything inside stays EventBridge-native.

flowchart LR
    subgraph inside [Inside the platform]
        direction LR
        SVC["A service<br/>(Content Lake, Contracts, Products)"]
        SVC -->|publishes| BUS["Platform bus<br/>platform-&lt;service&gt;"]
        BUS -->|filtered subscription| T["Your target<br/>Lambda · SQS · bus"]
    end
    BUS -->|watches| EV["Eventing service<br/>external catalogue"]
    EV -->|CloudEvents webhook| EXT["Your no-code<br/>automation"]

Read left to right: a service publishes to its platform bus; internal consumers (including your own AWS targets) subscribe directly to the EventBridge event; and tools outside the platform receive external catalogue events, published as CloudEvents by the Eventing service.

The naming convention

Platform event names are dot-separated and versioned:

platform.<service>.<entity>.v<major>.<verb>

• packt — the fixed prefix for platform events. Private events use internal. instead, so the two are never confused.
• <service> — the publishing service, e.g. content-lake, products.
• <entity> — the domain entity the event is about, e.g. resource, work, product, pricing.
• v<major> — the major version of the payload schema. Payloads evolve backwards-compatibly within a major version; a breaking change ships under a new major.
• <verb> — what happened, in the past tense, e.g. created, updated, published, rights_changed.

Some examples you will meet below:

platform.content-lake.resource.v1.created
platform.content-lake.work.v1.rights_changed
platform.products.product.v1.published
platform.products.pricing.v1.updated

Match on the event name (the detail-type) rather than parsing it — EventBridge pattern rules let you subscribe to, say, every platform.products.product.v1.* transition with one filter.

Platform, internal, external

Inside the platform, build only on the platform column. The private buses exist so a service can trigger its own downstream processing — search indexing, entity enrichment, image optimisation — and they are not consumable contracts. The external column is a different world: its events never appear on a platform bus, and platform events never reach a webhook — the two meet only inside the Eventing service.

The event envelope

Every event carries the EventBridge envelope. The event name is the detail-type; the publisher is identified by source (for example packt/svc-content-lake); and the domain payload is the detail object. Inside detail, three fields are always present, and enum fields carry their full protobuf identifiers on the wire (for example RESOURCE_TYPE_DOCUMENT, never DOCUMENT) — match those exact strings in your filters:

The rest of detail is specific to the event. A resource.created looks like this:

{
  "source": "packt/svc-content-lake",
  "detail-type": "platform.content-lake.resource.v1.created",
  "detail": {
    "event_id": "e_resource_created",
    "tenant_id": "packt",

    "resource_id": "res_ml_go_ch3",
    "work_id": "wk_ml_go",
    "version": null,
    "type": "RESOURCE_TYPE_DOCUMENT",
    "title": "Chapter 3 — Goroutines and Channels",
    "uri": "cl://packt/document/res_ml_go_ch3/latest",

    "source_id": "src_ml_go_manuscript",
    "generated_by": "act_ingest_ml_go",
    "language": "en",
    "tags": ["go", "concurrency", "chapter"],

    "occurred_at": "2026-06-20T09:12:00Z",
  },
}

At-least-once delivery and idempotent consumers

Delivery is at-least-once: the platform guarantees an event will reach your consumer, but it may occasionally arrive more than once — after a retry, say, or a redelivery. Your consumer must therefore be idempotent: processing the same event twice must have the same effect as processing it once.

The simple recipe is to deduplicate on event_id. Keep a record of the event_id values you have already handled, and skip any you have seen before:

def handle(event):
    detail = event["detail"]
    if already_processed(detail["event_id"]):
        return  # duplicate — safe to ignore
    do_the_work(detail)
    mark_processed(detail["event_id"])

The event catalogue

The tables below are the platform events you can subscribe to today, grouped by publishing service. Each is regenerated from the owning service's specification; that spec is always the source of truth for the full payload schema.

Content Lake — platform-content-lake

Published when Resources, Works, ContentUnits, Activities, or Sources change. Any service may subscribe.

The two rights events pair up: a change to a Contract triggers the Content Lake to re-resolve the affected Work's rights and publish work.rights_changed, which is your cue to recompute anything that depends on what may be done with that Work's content.

{
  "source": "packt/svc-content-lake",
  "detail-type": "platform.content-lake.work.v1.rights_changed",
  "detail": {
    "event_id": "e_work_rights_changed",
    "tenant_id": "packt",

    "work_id": "wk_ml_go",
    "contract_id": "ctr_chandra_2026",
    "contract_version": 3,
    "change_types": ["WORK_RIGHTS_CHANGE_TYPE_TERRITORIAL"],

    "occurred_at": "2026-04-01T12:00:00Z"
  }
}

Contracts — platform-contracts

Published by the Contracts service on every contract lifecycle event. Their primary consumer is the Content Lake, which reprojects rights on receipt — but any service may subscribe. Payloads are thin: IDs, version, and change_types only, never term content. Fetch terms from the Public API when you need them.

Contract events carry the contract's direction (CONTRACT_DIRECTION_INBOUND or CONTRACT_DIRECTION_OUTBOUND). The Content Lake ignores CONTRACT_DIRECTION_OUTBOUND events entirely — outbound contracts never affect resolved rights — and so should any consumer computing what may be done with content.

{
  "source": "packt/svc-contracts",
  "detail-type": "platform.contract.v1.rights_changed",
  "detail": {
    "event_id": "e_contract_rights_changed",
    "tenant_id": "packt",

    "contract_id": "ctr_chandra_2026",
    "version": 3,
    "change_types": ["RIGHTS_CHANGE_TYPE_TERRITORIAL", "RIGHTS_CHANGE_TYPE_USAGE"],
    "direction": "CONTRACT_DIRECTION_INBOUND",
    "work_ids": ["wk_ml_go"],

    "occurred_at": "2026-04-01T12:00:00Z"
  }
}

Usage — platform-usage

Consumption records, on their own high-volume bus. Every surface that serves content — the Public API, MCP tools, assistants — emits one platform.usage.content.v1.served event per served response, enumerating every piece of content the response drew on: the Resource and pinned version, its Work, whether it was shown or only consulted, whether it was cited, and the contract basis it was served under. This is the stream royalty attribution and AI-usage reporting are built on. An MCP answer that drew on 37 passages is one event with 37 items — the whole response, kept together.

The event contract is owned by the forthcoming Royalty service; treat the payload as append-only facts (what was served) rather than computed outcomes (what is owed) — the owing is derived downstream, so the division policy can be tuned without rewriting history.

Product Management — platform-products

Published on every Product lifecycle transition and on pricing, composition, and catalogue changes. The Distribution service is a major consumer, but any service may subscribe.

Note the distinction between product.v1.updated (product metadata changed) and content.v1.updated (the underlying Content Lake content a latest-tracking node points at changed). Subscribe to both if you need to react to any change to a Product.

Knowledge Graph — platform-content-lake-knowledge

The Knowledge Graph publishes entity lifecycle and metadata-refresh events (for example when a GitHub repository's stats or a technology's release information changes).

Webhooks and no-code tools

Everything above assumes an AWS target inside the platform. To receive events outside the platform — in a webhook endpoint you host, or in a no-code automation tool — the Eventing service is the plug-in point. It watches the platform buses and publishes a curated catalogue of external events, designed for workflow builders.

External events are not platform events re-wrapped:

• Names follow packt.<entity>.v<major>.<verb> — for example packt.order.v1.placed, packt.product.v1.published, packt.contract.v1.renewal_approaching. They name business entities, not internal services, and never reuse a platform event name — internal services can be split or renamed without your workflow noticing.
• Payloads are hand-authored for workflows: IDs and the facts you filter or branch on — never an internal payload passed through, and never personal data. A workflow that needs more calls back through the Public API with its own credentials.
• Versions are independent of the platform events behind an entry: an internal v1 → v2 migration never breaks your Zap.

Deliveries use the CloudEvents v1.0 envelope — the open, widely-supported format that tools like Zapier and n8n understand out of the box:

{
  "specversion": "1.0",
  "id": "0197f3a2-4b1c-7d3e-9a4f-2c8d1e5b6a70",
  "type": "packt.order.v1.placed",
  "source": "https://events.packtpub.services",
  "subject": "ord_9f4e2a71",
  "time": "2026-07-17T09:41:00Z",
  "datacontenttype": "application/json",
  "data": {
    "tenant_id": "packt",
    "order_id": "ord_9f4e2a71",
    "customer_id": "u_5c21d0aa",
    "vertical": "gamedev",
    "product_ids": ["prod_0197c1f4"],
    "channel": "shopify",
    "currency": "GBP",
    "total": "39.99"
  }
}

The at-least-once and idempotency rules apply to webhook delivery too: deduplicate on the id — it is stable across every redelivery of the same occurrence — and return a 2xx quickly so the Eventing service does not retry a delivery your handler already accepted.

See No-code & AI tools for connecting Zapier, n8n, and LLM agents end to end.

Verifying deliveries

Inside the platform, publishing is locked down with IAM: only the owning service can put events onto its bus, and only under its own source value. The source field on every event you receive is therefore trustworthy as-is — you never need to second-guess which service produced an event.

For webhook deliveries to your own endpoints:

• Deliveries authenticate to your endpoint with the credentials you configure on the destination — an API key header or an OAuth client. Treat possession of those credentials as proof the delivery came from the platform, and rotate them like any other secret.
• Payload signing arrives with the Eventing service: each delivery will carry a timestamped HMAC signature header computed with a per-destination secret, so you can verify origin and integrity even if your endpoint URL leaks. The scheme will be documented here when it ships.
• EventBridge itself does not sign deliveries — do not build against an x-eventbridge-signature header. Verify by credentials today, and by the platform signature once it is available.

Related pages

• The Public API — read the full state an event points at, using the IDs in the payload.
• Authentication — the WorkOS tokens your consumers and API calls carry.
• No-code & AI tools — wire events into Zapier, n8n, and AI agents as webhooks.
• Contracts & Rights — where contract events originate and how rights resolve.
• Content Lake — the estate whose lifecycle events are the platform signal of ingestion.
• Explorer — Chapter I — the service map and how events tie the platform together.