Skip to main content
Struct webhooks are event-driven: conditions are evaluated inline as on-chain activity is ingested, and a delivery fires the instant they are met. No polling loop sits between the event and your endpoint.

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

​
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.
Struct evaluates conditions inline with ingestion instead of re-querying on a timer, so neither limit applies. The same value Struct already updates on every on-chain event (PnL, volume, metrics, probabilities) is checked against your webhook conditions in the same path, and the delivery is sent the moment they match.

​
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.
Last modified on May 31, 2026