What are webhooks
Webhooks are HTTP callbacks that ContentEngine sends to a URL you specify whenever a supported event occurs in your workspace. Unlike polling an API at regular intervals, webhooks push data to your systems in real time when something changes, such as content generation finishing, a blog post publishing, or a social publish failing. This event-driven approach is more efficient than periodic polling and lets you build automations that react quickly to your content pipeline.
Each webhook delivery is a POST request containing a JSON payload with the event name, a timestamp, and the event data. Your receiving endpoint can then route that payload into Slack, n8n, Zapier, a deployment hook, or your own internal systems.
Setting up your first webhook
Navigate to Settings, then Webhooks in your ContentEngine dashboard. Click Add Webhook, choose one event type, and provide the destination URL you want ContentEngine to call. After saving, use the Test button in the webhook list to send a real delivery through the same retry and logging pipeline used for production events.
You can create multiple webhooks pointing at different URLs and subscribe each one to a different event type. For example, you might send publishing events to a Slack webhook, credits alerts to an ops endpoint, and social failures to an incident workflow. Each webhook operates independently, so a failure in one destination does not block deliveries to the others.
Available event types
ContentEngine currently supports these webhook events: generation_complete, post_published, post_failed, social_published, social_failed, approval_required, and credits_low. That set covers the key success, failure, approval, and usage transitions in the shipped product.
Each webhook subscribes to exactly one event type today. If you need broader coverage, create multiple webhook destinations or point several webhook configs at the same endpoint and branch on the incoming event field.
Monitoring webhook deliveries
The webhook dashboard includes a delivery log so you can inspect the status of each outbound attempt. For every delivery, you can see the event type, destination URL, attempt count, status, response code, and retry timing. This is the quickest way to debug a failing endpoint because it shows whether the request reached your service and whether ContentEngine scheduled another attempt.
The delivery log is especially useful after endpoint changes. Run a manual test delivery, confirm the endpoint returns a 2xx response, and then watch the log for real production events. If you see repeated failures, keep your handler fast and move slower downstream work into your own background jobs.
Handling failures and retries
ContentEngine uses retry scheduling for failed webhook deliveries. If your endpoint returns a non-success status code or times out, ContentEngine records the attempt and retries the delivery up to three total attempts with increasing delays. This helps smooth over transient outages without requiring you to replay every failure manually.
To minimize failures, ensure your endpoint responds within ten seconds and returns a 2xx status code as quickly as possible. If your downstream work takes longer than a few seconds, acknowledge the webhook immediately and continue processing asynchronously in your own queue. You should also make your handler idempotent so retries do not create duplicate side effects.
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 into ContentEngine, subscribe it to one event type, and then map the incoming payload to whatever downstream action you want.
For Slack, you can either send deliveries to a middleware endpoint that reformats the payload or point a webhook directly at a Slack incoming webhook URL for lightweight notifications. If you need richer routing, put a small HTTP service in front of Slack, inspect the event field, and transform the payload there. That keeps your ContentEngine configuration simple while giving you full control over formatting and fan-out.