What is a webhook trigger?
A webhook trigger is an inbound HTTP call that starts an AI worker the moment something happens in another system, instead of waiting for its next run.
A schedule asks "is there anything to do?" on a clock. A trigger is told. For work that must happen when something happens, being told is both faster and cheaper.
Trigger vs schedule
| Webhook trigger | Schedule | |
|---|---|---|
| Starts on | An event in another system | A clock, in your time zone |
| Latency | Seconds | Up to one interval |
| Cost when nothing happened | Nothing, it never fired | A run's worth of tool calls |
| Survives a missed event | No | Yes, the next run sweeps |
| Needs the sender configured | Yes, with a secret | No |
| Real kit | Inbound Lead Qualifier | Executive Daily Briefing |
When a trigger is the right answer
The test is latency, not importance.
Inbound Lead Qualifier is the clearest case: it connects email and CRM, and it runs on an event. A new inbound lead is qualified, filed in the CRM, and answered with a drafted first reply within minutes. On an hourly schedule the same kit would be up to an hour late, and in inbound sales an hour is the difference between first and forgotten.
Dynamic Focus-Time Optimizer shows the hybrid: it runs on demand, on a schedule and on events, so a calendar change can rearrange your focus blocks immediately while the schedule still does the 14-day sweep.
Use a schedule instead when the job has a natural rhythm: a morning brief, an end-of-day digest, an hourly queue sweep. Polling is fine when "within the hour" is fine.
What polling costs that a trigger does not
The cost argument is usually stronger than the latency one, and it is easy to work out. Take a worker that spends 6 tool calls checking for new work, on a day when 4 real events actually arrive:
| Approach | Runs a day | Tool calls a day | Worst-case latency |
|---|---|---|---|
| Every minute | 1,440 | 8,640, over every plan's cap | 60 seconds |
| Every 15 minutes | 96 | 576, over Free's 500 | 15 minutes |
| Hourly | 24 | 144 | 60 minutes |
| Webhook trigger | 4 | ~24 | Seconds |
The trigger does less work than the hourly schedule and reacts faster than the minute-by-minute one. That is unusual: normally latency is bought with cost. It happens here because polling spends its budget discovering that nothing happened, and an event-driven worker never runs on a quiet day at all.
Free allows 500 tool calls a day, Pro 5,000, and Team 50,000 pooled, so the top two rows are not only wasteful, they are unaffordable.
Use both, and not for redundancy
Most real workers want the pair, and the two jobs are genuinely different:
- The trigger handles events as they arrive.
- The schedule is the safety net for whatever the trigger missed, because the sending system was down, the payload was malformed, or the run errored.
Triggers travel over a network, and networks drop things. A worker with only a trigger has no way to notice it was never called. That is the failure mode a schedule quietly covers.
The trigger secret
A webhook URL is reachable by anyone who learns it, so each trigger is signed with a secret the calling system includes, and WorkerKit verifies it before running anything.
Two consequences worth planning for:
- The secret can be rotated, and the sending system must be updated when it is. A stale secret shows up as refused calls, not as silent success.
- The wire format is disclosed rather than magic, so you can configure a sender that has never heard of WorkerKit.
Every trigger leaves a receipt
A triggered run writes the same receipt as a scheduled one, and the receipt carries the payload the run was started with.
That matters more for triggers than for schedules. When a triggered run does something surprising, the first question is always "what was it actually sent?", and the receipt is the answer.
FAQ
What is the difference between a webhook trigger and a schedule?
A schedule starts a worker on a clock in your own time zone. A webhook trigger starts it when another system sends an HTTP call, so the worker reacts within seconds instead of waiting for its next interval. Many workers use both, with the schedule acting as a safety net for missed events.
Can one worker have both a trigger and a schedule?
Yes, and it is the usual setup for anything time-sensitive. Dynamic Focus-Time Optimizer runs on demand, on a schedule and on events at once.
How is a webhook trigger secured?
Each trigger is signed with a secret that the calling system includes, verified before anything runs. Secrets can be rotated, and a stale secret produces refused calls rather than silent failures.
Do triggered runs count against my tool call limit?
Yes. A run costs the same tool calls however it started. The saving from a trigger is that it does not fire at all when nothing happened, where a frequent schedule spends calls checking.
Can I see what payload started a run?
Yes. The run receipt carries the run context including the payload the webhook delivered, which is what makes a surprising triggered run diagnosable rather than a mystery.