Fires the instant it happens
Conditions are checked as each on-chain event lands, so the webhook goes out the moment a threshold is crossed. No polling interval delaying it.
Scales to hundreds of thousands
No per-subscription polling cost means you can run hundreds of thousands of active webhooks, where polling stacks top out at a few hundred.
How it compares
| Polling (cron) | Struct (event-driven) | |
|---|---|---|
| When it fires | Next poll after the event | The moment the condition is met |
| Freshness | Up to 30s behind real time | No polling delay |
| Active webhooks supported | Hundreds | Hundreds of thousands |
Why polling falls short
Many webhook providers run a scheduled job (a cron) that periodically re-queries the data and emits a webhook if the query returns something new. That design carries two costs:- A latency floor. A delivery is only ever as fresh as the polling interval. A job that runs every 30 seconds can leave you 30 seconds behind real time even when the event happened immediately.
- A scale ceiling. Every subscription adds another query to every cycle, so work grows with subscriptions multiplied by frequency. Polling stacks top out at a few hundred active webhooks before the job can no longer keep up.
What this means for you
- Set thresholds as tight as you like; each delivery reflects the exact moment the condition is crossed.
- Run a webhook per trader, per market, or per user, and scale to as many as your plan allows. See Limits for per-plan counts.
- Power time-sensitive automations (copy-trading, liquidation triggers, alerts) that act on the event itself, the instant it happens.