The generic webhook ingest pattern that turns any business event — a closed deal, a Stripe milestone, a tagged Notion page — into a content trigger. How to wire it via Zapier, Make, n8n, or direct POST, what the payload discipline must be, and why the fact-anchor gate still runs on event-sourced content.
A webhook content pipeline accepts an HTTP POST carrying event data from any external system — a CRM deal closing, a Stripe subscription milestone, a Notion page publishing, a GitHub release tagging — and runs the relevant fields through an AI generation pipeline governed by your Persona Brief. It is the most general of the input sources: where RSS handles "a new feed item exists" and Gmail handles "a new labeled email exists," webhooks handle every other event in your business. Basic setup is about 30 minutes via Zapier or Make. The non-obvious requirements are idempotency (so retries do not double-publish), payload hygiene (strip secrets and PII before generation), and the fact-anchor gate (event payloads can carry unverified claims too).
RSS and Gmail each cover one shape of trigger: a feed updating, an email being labeled. Webhooks cover everything else — every event in your business that could justify a piece of content but does not arrive as a feed or an email. Closed a deal worth a case study? An event fired somewhere. Shipped a release? Hit a revenue milestone? A customer crossed a usage threshold? Each of those is an event your systems already emit, and each is a content trigger you are currently ignoring because nobody is sitting in the CRM waiting to write a post.
The webhook pattern wires those events directly into generation. The source system POSTs a payload the moment the event happens, the pipeline pulls the fields worth turning into content, and a draft comes out the other side governed by your Persona Brief. This is the most flexible input source Kompozy supports, and also the one with the most ways to get the plumbing wrong — retry storms, leaked secrets, rate spikes. This guide is the honest version: the pattern, the four wiring options with real prices, the payload discipline that keeps it safe, and why event-sourced content still runs the same verification gates as everything else. Pairs with [apify-scraping-to-content](/content-automation/apify-scraping-to-content) for the scraper source and [gmail-to-content](/content-automation/gmail-to-content) for the inbox source.
Kompozy ingests content from five source types: RSS feeds, Apify scrapers, Gmail, webhooks, and in-app uploads. Four of those are specific — a feed, a scraper, an inbox, a file. The webhook source is the general case that catches everything the specific four do not. Anything that can be expressed as "when X happens in some system, make content about it" is a webhook trigger, because almost every modern tool can fire an HTTP POST when something happens inside it.
Mechanically, a webhook is just an inbound HTTP request carrying a JSON payload. The pipeline treats that payload the same way it treats any other source: the relevant fields become raw_content, Claude transforms them against your Persona Brief into a draft, the draft runs the four quality gates, and whatever clears routes to autopilot or review, then the scheduler, then publish. The webhook does not get a fast lane around the gates — it is a source like any other, and event-sourced data needs the same scrutiny as feed-sourced or scraped data. What makes webhooks distinctive is not the downstream pipeline, which is shared; it is the breadth of what can trigger them and the plumbing discipline that breadth demands.
That framing matters because the failure modes specific to webhooks all live in the ingest layer — the part before raw_content — not in generation. Get the trigger, the payload, and the idempotency right and the rest of the pipeline behaves exactly as it does for RSS. Get them wrong and you get duplicate posts, leaked customer data, or a queue overflowing during a traffic spike. The sections below are mostly about getting the ingest layer right. See [autopilot-explained](/autonomous/autopilot-explained) for how an event source rides the autopilot loop.
The end-to-end setup is four decisions and a configuration. Walk them in order:
The single most important configuration choice is which fields you map. A webhook payload typically carries far more than you want to generate from — internal IDs, system metadata, secrets, customer PII. Mapping only the content-relevant fields is both a quality decision (the model generates from signal, not noise) and a safety decision (secrets and PII never reach generation if you never map them). The payload discipline section below treats this as the load-bearing control it is.
There are four ways to get an event from its source to the Kompozy endpoint, and they trade ease of setup against cost and control. The right one depends on how technical your team is and how much middleware tax you are willing to pay:
| Wiring option | Best for | Pricing | Trade-off |
|---|---|---|---|
| Zapier | Non-technical operators, fast setup | Free / Pro $19.99/mo / Team ~$69/mo | Per-task billing gets costly at high event volume |
| Make | Value at moderate complexity | Core ~$9/mo (10,000 operations) | Per-operation model; complex scenarios cost more per event |
| n8n | Technical teams, custom transforms | Self-host free; cloud qualitative | You own the infra (or pay for managed cloud) |
| Direct POST | Your own software as the source | No middleware cost | You own and maintain the integration code |
A note on choosing: the glue tools earn their cost when the source is a third-party app you cannot modify, because they handle the auth and the polling for you. The moment the source is your own code, a direct POST is both cheaper and cleaner — you skip the middleware entirely and emit exactly the payload the receiver wants. Many mature setups end up mixed: glue for the SaaS sources, direct POST for the home-grown ones.
The pattern is only worth the plumbing if the events you wire produce content people want to read. The ones that consistently land share a quality: the event marks a moment that is genuinely interesting to your audience, not just to your operations team. The high-yield patterns:
The connective tissue across these is that the event is a fact ("a deal closed," "a release shipped") and the content is your interpretation of it, written in your voice. The pipeline is not inventing the milestone; it is dressing a real event in your brand and shipping it fast. That is the legitimate core of event-driven content.
The webhook-specific failure modes all live in how the payload is handled at ingest. Three controls are non-negotiable, and skipping any one produces a specific, predictable failure:
A fourth control is operational rather than per-payload: build a daily reconciliation job. CRMs and other sources occasionally fail to fire a webhook at all, silently. A job that compares "events that should have fired today" (deals closed today) against "content generated today" catches the silent misses that no error log will show you, because a webhook that never fired leaves no trace on your side. This is the same reconciliation discipline that catches dropped feed items in RSS — events that do not arrive are invisible until you go looking for the gap.
| Failure mode | What it looks like | The control | Where it lives |
|---|---|---|---|
| Retry storm | Same post published repeatedly | Dedup on unique event id | Receiver, by default |
| Leaked secret / PII | API key or customer data in generated text | Allow-list field mapping | Receiver config |
| Rate spike | Queue overflow, flood of low-value posts | Hard cap of N events/minute | Receiver throttle |
| Silent source failure | Event never fired, no error anywhere | Daily reconciliation job | Scheduled audit |
It is tempting to assume event data is trustworthy because it came from your own systems — but the payload often carries fields you did not author. A CRM "win reason" is a sales rep's free-text note. A Slack wins-channel message is whatever someone typed. A customer testimonial pulled from a support thread is the customer's words, possibly with claims you cannot verify. When the pipeline generates content from those fields, the same hallucination and contamination risks apply as with any other source.
So the fact-anchor gate runs on event-sourced content exactly as it does on scraped or feed content. After generation, it checks every numeric claim, quote, and entity in the draft against the ingested payload. If the model invents a stat that was not in the event, the output is rejected and regenerated. If the payload itself carried an unverified claim — a rep's optimistic "saved them 40% on costs" note — the gate confirms the number traces to the source but cannot confirm the number is true, the same contamination gap that scraped sources have. Event-sourced numerics from free-text fields warrant the same human spot-check as scraped ones. Structured, system-generated fields (a Stripe amount, a customer count) are trustworthy; free-text human-entered fields are not. The gate plus a reviewer pass on the free-text claims is the safe configuration. Full mechanism in [fact-anchor-gate](/autonomous/fact-anchor-gate).
Webhooks are the right source for discrete business events and the wrong source for several adjacent jobs. The boundaries:
Webhooks are the general-purpose content trigger: any event your systems already emit can become a piece of content in your voice, shipped within minutes of the event firing. The pattern is genuinely about 30 minutes to wire per source, but the durable work is the ingest-layer discipline — idempotency so retries do not double-publish, allow-list field mapping so secrets and PII never reach generation, a rate cap so spikes do not flood the queue, and a reconciliation job so silent misses surface. Event data is not automatically trustworthy, so the fact-anchor gate runs the same as on any source, with a human pass on free-text claims. Wire the events that mark interesting moments, keep the plumbing clean, and the webhook source turns your business's own activity into a steady content engine. Start with [pricing](/pricing) to size the content-engine tier, and see [apify-scraping-to-content](/content-automation/apify-scraping-to-content) for the scraper source that rides the same webhook ingest.
A pipeline that accepts an HTTP POST carrying event data from any external system — a CRM, Stripe, Notion, GitHub, Slack — and runs the relevant fields through AI content generation governed by your Persona Brief. It is the most general input source: it handles every business event that does not arrive as an RSS feed or a labeled email.
Not necessarily. Zapier and Make let you wire a source event to the Kompozy endpoint visually with no code, which covers most non-technical setups in about 30 minutes. Technical teams that want custom data transformations or no per-task billing can use self-hosted n8n or a direct HTTP POST from their own software.
RSS is a poll model — the pipeline checks a feed on an interval and ingests new items. Webhooks are a push model — the source fires the moment an event happens, so generation starts within sub-minute. Webhooks also handle events that do not fit the feed shape at all, like a CRM deal closing or a Stripe milestone. Use RSS for feeds, webhooks for everything else.
Idempotency. The receiver keys on a unique event id from the payload — a Stripe charge_id, a CRM event id — and refuses to process the same id twice. Without this, an aggressive source retrying after a 5xx will republish the same content repeatedly. A mature pipeline implements dedup by default; if you build the receiver yourself, it is the first control to add.
Allow-list the fields you map rather than block-listing the ones you fear. In the receiver configuration, map only the content-relevant fields — the company name and win reason, not the internal IDs, API keys, or customer email addresses. Anything you never map never reaches the model, which is a cleaner guarantee than trying to scrub a full payload after the fact.
Yes. Once the webhook payload is ingested as raw_content and generated against the Persona Brief, the output fans out across all configured platforms per the bucket allocation — TikTok, Instagram, LinkedIn, X, and the rest — the same as any other source. The webhook is only the trigger; the multi-platform publishing is shared pipeline behavior.
Yes. Webhook payloads often carry free-text human-entered fields — a sales rep's win-reason note, a customer testimonial — that can contain unverified claims. The fact-anchor gate runs on event-sourced content exactly as on any source: it blocks claims the model invents, and it confirms surviving claims trace to the payload. Free-text numeric claims still warrant a human spot-check, since the gate cannot vouch for the truth of a note someone typed.
Generation typically starts within sub-minute of the webhook firing, because the push model has no polling delay. Total time-to-publish then depends on your review settings — near-immediate on autopilot, or longer with a manual review cooling window. The sub-minute figure is the time to generation start, not to publish.