Two fundamentally different ways an automation can learn that something happened: webhooks, where the source pushes you a notification the instant an event occurs, and polling, where you ask "anything new?" on a schedule. FeedForce's Trigger node is built entirely on the second model — manual runs or timer/cron schedules, no webhook listener. That's a real design trade-off worth understanding rather than a missing checkbox.
The actual difference
Webhooks require the source to support pushing events to a URL you control — the source calls you the moment something happens, so there's no delay and no wasted checking. The catch: the source has to build and maintain that capability, and you need a stable, publicly reachable endpoint to receive it. Not every API offers this, and the ones that do vary widely in how reliably they deliver.
Polling flips the responsibility — you ask on a schedule, via an HTTP Request node. The source doesn't need to support anything special; if it returns JSON when you call it, you can poll it. The cost is a small delay (up to however long your polling interval is) and calls that sometimes find nothing new.
Why polling is the more honest default for content automation
Most of the sources a content automation actually cares about — news feeds, price APIs, sports scores, your own product data — either don't offer webhooks at all, or offer them behind enterprise tiers most creators and small teams don't have. Building a trigger model around webhooks would mean the majority of realistic data sources simply couldn't drive a workflow. Polling works with essentially anything that returns data, which is why it's the trigger model that actually covers real use.
There's also an honesty argument: a webhook that silently stops arriving (a source's delivery breaks, a URL becomes unreachable) fails invisibly — your workflow just stops running with no obvious signal. A polling trigger that stops finding new data is far easier to notice and debug, because you can always manually run it and see exactly what the source returns right now.
The real cost of polling: a small delay, not a big one
The tightest custom cron interval (*/15 * * * * — every 15 minutes, or tighter) gets a genuinely time-sensitive workflow close enough to real-time that the difference from a hypothetical webhook rarely matters for content — see Trigger timing recipes for picking an interval that fits how fast your specific niche actually moves. A 15-minute worst-case delay on a newsjacking reaction is a rounding error next to the hours a fully manual process takes.
What this means for how you design a workflow
Don't build around "the instant this happens" — build around "the first time this run notices it happened," and pick a polling interval that makes that gap small enough for your format. For genuinely urgent reactions (see automating newsjacking), that means a tight interval and a relevance/recency filter, not a wish for webhooks that most of your real sources wouldn't offer anyway. The trigger model FeedForce actually has covers the sources that matter; designing against its real shape, rather than an idealized instant-push model, is what makes a workflow reliable in practice.