> ## Documentation Index
> Fetch the complete documentation index at: https://docs.struct.to/llms.txt
> Use this file to discover all available pages before exploring further.

# Instant Delivery

> Struct evaluates and delivers webhooks the moment a condition is met, not on a polling cycle.

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.

<CardGroup cols={2}>
  <Card title="Fires the instant it happens" icon="bolt">
    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.
  </Card>

  <Card title="Scales to hundreds of thousands" icon="layer-group">
    No per-subscription polling cost means you can run **hundreds of thousands** of active webhooks, where polling stacks top out at a few hundred.
  </Card>
</CardGroup>

## 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.

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](/webhooks/getting-started#limits) for per-plan counts.
* Power time-sensitive automations (copy-trading, liquidation triggers, alerts) that act on the event itself, the instant it happens.