Webhook content pipelines in 2026: routing business events into Kompozy

Published 2026-05-19 · Updated 2026-10-23

RSS and Gmail each cover one shape of trigger: a feed updating, an email being forwarded. 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.

Kompozy has no inbound webhook endpoint. Its automatic input is the RSS source, which it polls on a schedule, so the working pattern puts a glue tool in the middle. The source system fires a webhook at Zapier (or a similar tool), the glue step writes the fields worth turning into content as an item in an RSS feed, and Kompozy picks that item up and drafts from it in your Persona Brief's voice. Going the other way, Kompozy can push finished blog posts to your own endpoint as a signed webhook. The plumbing still has plenty of ways to go wrong: retry storms, leaked secrets, rate spikes. This guide is the honest version: the pattern, the four wiring options, the payload discipline that keeps it safe, and why event-sourced content still needs a human fact check like everything else. Pairs with apify-scraping-to-content for the scraper source and gmail-to-content for the inbox source.

Where do webhooks fit among the input sources?

Webhooks are the general case. They catch the events that are not a feed, an inbox or a file. Kompozy's built-in inputs are narrower than that: the RSS source polls feeds, in-app uploads cover files, the Brand Prompt lane generates from your Persona Brief with no source, and the email-forwarding source is still pending provider setup. There is no inbound webhook, so in Kompozy an event arrives as a feed item. 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 an HTTP request carrying a JSON payload. Once the glue step has turned the fields you chose into a feed item, Kompozy treats it like any other RSS item: it becomes raw_content, Claude transforms it against your Persona Brief into a draft, the draft waits for approval or, with Auto-Publish Generated on, is approved automatically, then the scheduler, then publish. The webhook does not get a fast lane; 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 for how an event source rides the autopilot loop.

How do you set up a webhook content pipeline?

The end-to-end setup is four decisions and a configuration. Walk them in order:

1. Pick the event source. A CRM firing on a deal moving to closed-won. Stripe firing on a subscription created or a revenue threshold crossed. Notion firing on a page published to a specific database. GitHub firing on a release tagged. Calendly firing on a meeting completed. The source is whatever system already knows the thing happened.
2. Send the event to a glue tool, not to Kompozy, which has no inbound webhook endpoint. In Zapier, use the source app's own trigger if Zapier supports it, or the Webhooks by Zapier Catch Hook trigger, which gives you a URL the source can POST to.
3. Turn the event into a feed item. Zapier's RSS by Zapier Create Item in Feed action asks for a title, a link and a description, which forces the real decision: the deal's "company name" and "win reason" go into the description, and the internal deal ID does not.
4. Add the feed's URL as an RSS source in Kompozy and choose which formats it may produce. On the next poll (every 15 minutes by default), the new item becomes raw_content, Kompozy generates a draft against the Persona Brief, and the draft waits for review or goes to the schedule, depending on whether Auto-Publish Generated is on.

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.

Should you wire events through Zapier, Make, n8n, or your own feed?

Zapier is the easiest of the four ways to turn an event into a feed item Kompozy can poll, especially for non-technical operators. Whichever you pick, the last step has to produce an RSS feed, because that is the only way an event reaches Kompozy. The options 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:

• Zapier — the easiest for non-technical operators. Connect a trigger from one of thousands of integrated apps to an RSS by Zapier feed, and point Kompozy at that feed. Zapier bills by task count, so a high event volume is where it gets expensive; check its pricing page for current tiers.
• Make (formerly Integromat) — more flexible than Zapier, with a slightly steeper learning curve. It bills on usage, so complex multi-step scenarios cost more per event. Many teams move to it once their scenarios get non-trivial.
• n8n — you can self-host it, in which case you pay for the infrastructure you run it on rather than per task. This is the right call for technical teams that want custom data transformations, no per-task billing, and full control over where the data flows. n8n also offers a managed cloud tier if you do not want to host it yourself.
• Your own feed. If the source is your own software, publish the events as an RSS feed from your app or a backend job and skip the middleware. You pay no middleware tax and control exactly what each item says, but you own the code. This is the cleanest option when the source is your own software.

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. Once the source is your own code, publishing your own feed is cheaper and cleaner, because you skip the middleware and write exactly the items you want. Many setups end up mixed: glue for the SaaS sources, a home-grown feed for the in-house ones.

Which business events make good content?

The events that land mark a moment that is genuinely interesting to your audience, not just to your operations team. The pattern is only worth the plumbing if the content gets read. The high-yield patterns:

• CRM deal closed, tagged as case-study-willing, fires a testimonial post. The rep marks the deal as consenting during close; the webhook fires; the pipeline generates a LinkedIn post plus a quote graphic. The consent tag is what keeps this ethical — see the payload discipline section.
• Stripe revenue or customer milestone fires a celebration post. The 100th customer, the 500th, a $100k MRR mark — each is a credibility signal worth a thread. The event is the trigger; the Persona Brief keeps the celebration in your voice rather than generic.
• Calendly meeting completed fires follow-up content. A founder does a podcast guest spot; the webhook fires when the recording is delivered; the pipeline kicks off a repurpose. This is the bridge between event automation and the broader content-repurposing workflow.
• GitHub release tagged fires a product-update post. A new version ships; the release notes become a "what is new in v2.4" thread plus a LinkedIn post, generated the moment the tag lands rather than days later when someone remembers to write it.
• Notion page published to a public database fires a thought-leadership post. An internal strategy doc that the team decides to externalize gets turned into a public-facing draft, with the decision to publish made by a human applying the trigger label, not by the model.
• Slack message in a wins channel fires a social-proof post. Customer praise shared internally becomes external content — with the same consent discipline as the CRM case-study pattern, because customer words still require customer permission.

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.

What payload controls does a webhook pipeline need?

Three controls are non-negotiable: idempotency, secret handling, and rate limits. The webhook-specific failure modes all live in how the payload is handled at ingest, and skipping any one control produces a specific, predictable failure:

1. Idempotency. If the receiver returns a 5xx, the source retries — and many sources retry aggressively, sometimes for hours. Without a dedup key, every retry generates and publishes the same content again. The fix is to key on a unique event id from the payload (a Stripe charge_id, a CRM event id) and refuse to process the same id twice. On Kompozy's side, the RSS source skips any item whose GUID (or ID, or link) it has already stored, so build that value from the event id and a retried event comes back as the same item. Dedup in the glue step too, so a retry does not create a second feed item.
2. Payload hygiene. Webhook payloads routinely carry secrets and PII — API keys, customer email addresses, credit-card fragments, internal identifiers. Strip every field you are not deliberately generating from before the payload reaches the model. The clean way to enforce this is the field-mapping step: map only the content-relevant fields, and the rest never touch generation because they were never selected. Allow-list the fields you want rather than block-list the ones you fear.
3. Rate limiting. A spike of a hundred events in a minute can overflow the queue and either drop events or generate a flood of low-value posts. Cap the events per minute in the glue step and let the overflow wait rather than fan out. In Kompozy, each RSS source also has a max-items-per-poll setting that limits how many new items one poll takes. A burst of CRM events from a bulk import should not become a burst of published posts.

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.

Why does event data still need a fact check?

Event payloads often carry fields you did not author, so data from your own systems is not automatically trustworthy. 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.

Kompozy tells the model not to invent figures, dates or sources for every source, event data included, but it does not check the draft against the payload afterward, so an invented stat is not rejected automatically. If the payload itself carried an unverified claim — a rep's optimistic "saved them 40% on costs" note — the draft can repeat it faithfully, and nothing confirms 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. A reviewer pass on every number, free-text claims above all, is the safe configuration. What Kompozy does and does not check is in fact-anchor-gate.

The wiring is the quick part. The durable engineering work is idempotency, allow-list field mapping and the daily reconciliation job, because those controls stop retries, leaks and silent misses from piling up. Teams that treat the wiring as the whole job ship a pipeline that double-publishes on the first retry storm.

Webhooks push and RSS feeds are polled. Because Kompozy only polls, an event routed through a feed waits for the next poll, every 15 minutes by default. Time to publish still depends on your review window.

Can Kompozy send a webhook when it publishes?

Yes, for blog posts. Kompozy's Custom Webhook blog destination sends each published blog article to an HTTPS endpoint you own as a JSON POST with the event name blog.publish, carrying the title, slug, markdown, HTML, excerpt, tags and hero image. If you set a shared secret, the request carries an X-BKE-Signature header with an HMAC-SHA256 of the body, so your receiver can confirm the post came from Kompozy. A test button in Settings sends a sample payload and reports whether your endpoint answered with a 2xx. Social posts go out through Kompozy's platform connections, not through this webhook.

When should you not use a webhook source?

Webhooks are the right source for discrete business events and the wrong source for several adjacent jobs. The boundaries:

• If the trigger is a feed updating, use RSS, not a webhook. RSS is purpose-built for "new item in a feed" and handles the polling and dedup for you. Forcing a feed through a webhook glue layer adds cost and a failure point for no benefit.
• If the trigger is an email you want to amplify, use the Email Newsletter source once its inbound delivery is live. Kompozy has it in settings, but the app still marks delivery as pending provider setup. Forwarding is simpler than routing email through a webhook and a feed.
• If the event volume is high but the events are low-value, do not wire it. A webhook that fires on every minor CRM field change floods the queue with content nobody wants. Wire the events that mark genuinely interesting moments; ignore the operational noise.
• If the content is evergreen rather than event-driven, there is no event to trigger on. Use a Persona Brief topic pool or scheduled generation instead. Webhooks are for reacting to things that happen, not for steady-state publishing.

When is a webhook the right content trigger?

When a business event, not a feed or an email, should trigger the content. Any event your systems already emit can become a piece of content in your voice. Wiring each source is quick, 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 give every number a human check, free-text claims above all. 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 to size the content-engine tier, and see apify-scraping-to-content for scraped data, which reaches Kompozy the same way, through a feed.

What does this look like in Kompozy?

A photo post generated in the Kompozy workspace, the kind of asset a customer-win or release event can become.

Who is this for, and who should skip it?

Best for:

• SaaS teams that want releases, milestones and customer wins turned into drafts
• Teams already on Zapier who can add a feed step
• Companies with consent-tagged case-study deals in a CRM
• Developers who want published blog posts pushed to their own site by webhook

Not ideal for:

• Anyone who needs Kompozy to accept a direct POST; there is no inbound endpoint
• Feed-based sources; point the RSS source at them directly
• Evergreen content with no triggering event
• High-volume, low-value events that would flood the queue

Frequently asked questions

How do we know this?

On 2026-10-23 we checked Kompozy's API routes and workers. There is no inbound content webhook, the RSS source is polled every 15 minutes by default and skips items it has already stored, and the Custom Webhook blog destination sends HMAC-signed POSTs. We checked Zapier's Catch Hook and RSS by Zapier steps on zapier.com the same day and removed connector prices we did not confirm.

Sources

1. Kompozy — Integrations (read 2026-10-23)
2. Kompozy — Pricing (read 2026-10-23)
3. Zapier — Webhooks by Zapier (Catch Hook trigger) (read 2026-10-23)
4. Zapier — RSS by Zapier (Create Item in Feed action) (read 2026-10-23)

Which other content automation guides should you read next?

• RSS-to-social automation: the complete setup for podcast and blog feeds — How to wire RSS feeds (podcast hosts, Substack, Ghost, WordPress) directly into a content generation pipeline that fans out to 9 platforms automatically.
• Web scraping to content: the Apify → AI → social workflow — Kompozy has no Apify connector. Export a scraper's dataset as RSS, poll it like any feed, and check every scraped number by hand.
• Gmail-to-content automation: turning newsletters and emails into social posts — Forward newsletters and threads to a workspace ingest address with an allowed-senders list. Kompozy still shows inbound delivery as pending provider setup.
• Content automation in 2026: definition, mechanics, and what it is not — The clean definition of content automation, what separates it from scheduling, and the 4 layers every real automation pipeline needs.
• The 7 ways content automation breaks (and how to detect each) — Drift, hallucinations, platform deprecations, OAuth expirations, rate-limit blocks, queue overflow, voice degradation — the 7 failure modes every automation operator must monitor.

Which related Kompozy topics cover this next?

• Autonomous Content Creation — How Kompozy autopilot really works: one workspace switch that approves and schedules generated posts, the checks that run before they publish, and a 14-day ramp for turning it on.

← Back to Content Automation overview · Get started →