What are webhooks
Webhooks are HTTP callbacks that ContentEngine sends to a URL you specify whenever a specific event occurs in your workspace. Unlike polling an API at regular intervals, webhooks push data to your systems in real time the moment something happens, such as a new post being published, a draft reaching review status, or an analytics threshold being crossed. This event-driven architecture is more efficient and responsive than periodic polling and enables you to build automations that react instantly to changes in your content workflow.
Each webhook delivery is a POST request containing a JSON payload with details about the event, including the event type, a timestamp, the affected resource, and any relevant metadata. Your receiving endpoint processes this payload and takes whatever action you define, whether that is sending a Slack notification, updating a project management board, triggering a deployment, or syncing data to a data warehouse.
Setting up your first webhook
Navigate to Settings, then Webhooks in your ContentEngine dashboard. Click 'Add Webhook' and enter a descriptive name, the destination URL where you want events sent, and select the event types you want to subscribe to. ContentEngine will send a test ping to your URL to verify it is reachable and returns a 200 status code. If the ping fails, double-check that your endpoint is publicly accessible and that any firewalls or authentication layers allow incoming POST requests from ContentEngine's IP range.
Once the ping succeeds, your webhook is active and will begin receiving events. You can create multiple webhooks pointing to different URLs and subscribing to different event sets. For example, you might send publishing events to your Slack channel and analytics events to your data warehouse. Each webhook operates independently, so a failure in one does not affect delivery to others.
Available event types
ContentEngine supports a comprehensive set of webhook event types organized into categories. Content events include post.created, post.published, post.updated, and post.archived, which fire at each stage of the content lifecycle. Workflow events include draft.submitted, draft.approved, and draft.rejected, which track the editorial review process. Analytics events include analytics.milestone and analytics.alert, which fire when a piece of content hits a performance threshold you define.
Additional event types cover workspace management, user activity, and integration status changes. You can subscribe to individual events or use wildcard patterns to receive all events in a category. The full list of event types with example payloads is available in the webhook documentation. When starting out, subscribe to a small set of events and expand as you build confidence in your integration, rather than subscribing to everything at once and being overwhelmed by the volume of deliveries.
Monitoring webhook deliveries
The webhook dashboard includes a delivery log that shows every event sent in the last thirty days. Each log entry displays the event type, destination URL, HTTP status code returned by your endpoint, response time, and the full request and response bodies. This log is essential for debugging integration issues because it lets you see exactly what ContentEngine sent and how your endpoint responded.
You can filter the delivery log by event type, status code, and date range to quickly isolate problems. Successful deliveries show a green status indicator while failures show red. Click any delivery to expand its details and see the full JSON payload. If you need to replay a failed delivery after fixing your endpoint, click the Retry button to resend the exact same payload. This saves you from having to manually trigger the event again in your workspace.
Handling failures and retries
ContentEngine uses an exponential backoff retry strategy for failed webhook deliveries. If your endpoint returns a non-success status code or times out, ContentEngine will retry the delivery up to five times over a period of approximately four hours. The retry intervals increase with each attempt to give your systems time to recover from transient issues. If all retries fail, the delivery is marked as permanently failed and you receive an email notification.
To minimize failures, ensure your endpoint responds within ten seconds and returns a 200 status code as quickly as possible. If the processing logic takes longer than a few seconds, accept the webhook immediately and process it asynchronously in a background job. This pattern prevents timeouts and ensures ContentEngine receives a success response promptly. You should also implement idempotency in your handler so that retried deliveries do not create duplicate actions in your downstream systems.
Common integration patterns (Zapier, n8n, Slack)
Zapier and n8n both support incoming webhooks as triggers, making them natural companions for ContentEngine. In Zapier, create a new Zap with 'Webhooks by Zapier' as the trigger and select 'Catch Hook.' Copy the generated URL and paste it into ContentEngine as a new webhook endpoint. From there, you can connect any of Zapier's thousands of app integrations as actions, such as creating a Trello card when a draft is submitted for review or adding a row to a Google Sheet when a post is published.
For Slack integration, you can either use a Zapier or n8n intermediary or send webhooks directly to a Slack incoming webhook URL. ContentEngine's payload format is compatible with Slack's message attachment structure, so you can receive rich notifications with the post title, author, and a direct link back to ContentEngine. For more advanced setups, build a lightweight middleware service that transforms ContentEngine webhook payloads into whatever format your downstream tools expect. This decoupling gives you maximum flexibility to change tools without reconfiguring your ContentEngine webhooks.