Webhooks reference

Release and event webhook payloads.

Creytix Connect registry — abstract operator panel with native tool lanes

Overview

When something happens to your site — a release publishes, a page goes live — Creytix Ship can notify your own systems instead of making you poll for changes. This page describes the shape of those events at a level you can build against: what triggers a webhook, and what the payload looks like.

How it works

A webhook is a URL you register that Creytix calls when a subscribed event happens:

You register an endpoint and choose which event types you want to hear about.
When a matching event happens — a release publishes, for example — Creytix sends a JSON payload to your endpoint.
Your endpoint acknowledges receipt; if it doesn't, Creytix retries on a backoff schedule.

Every payload shares the same envelope — an event name, a timestamp, the resource it's about, and a status — so you can write one handler and branch on event type rather than parsing a different shape per event.

Steps

•
Open Ship in the Control Panel
From Ship, find the webhooks section for your workspace.
•
Add an endpoint
Register the URL you want Creytix to call.
•
Choose your events
Subscribe to the event types you care about — release published, release failed, and so on — rather than receiving everything by default.
•
Send a test event
Trigger a test delivery to confirm your endpoint receives and acknowledges the payload correctly.
•
Handle retries in your endpoint
Make sure your endpoint responds quickly and idempotently — Creytix retries deliveries that don't get acknowledged, so your handler may see the same event more than once.

Capabilities

Event-driven, not polling — your systems hear about a release the moment it happens.
Consistent payload envelope — every event shares the same top-level shape (event, timestamp, resource, status), whatever the event type.
Selective subscriptions — choose which event types you actually want delivered.
Retried delivery — a failed delivery attempt is retried rather than silently dropped.

A generic payload looks like this:

{
  "event": "release.published",
  "timestamp": "2026-07-01T14:32:00Z",
  "workspace": "your-workspace-id",
  "resource": {
    "type": "page",
    "id": "your-resource-id"
  },
  "status": "success"
}

Limits & honest scope

Webhooks cover the common release lifecycle today, not a full event bus.