## Polling pattern

A typical polling loop:

1. Read the `last_polled_at` timestamp from your pipeline’s state store.
2. Query ION for records where `updatedAt > last_polled_at`.
3. Transform and forward the results to your SIEM ingest endpoint.
4. On success, write the current timestamp as the new `last_polled_at`.

The data most commonly relevant to SIEM ingestion includes:

- **Runs**: production order lifecycle events (created, started, completed, paused).
- **Issues**: quality events, nonconformances, and dispositions.
- **Inventory**: adjustments, transfers, and lot/serial number changes.
- **Users and roles**: membership changes, permission grants, and deactivations.

## Alternatives to polling

If your architecture can accept inbound HTTPS traffic, [webhooks](https://docs.firstresonance.io/api-reference/guides/webhooks) let ION push change events to your endpoint in near-real time, which reduces polling overhead and latency. Webhooks cover the same resources and include the before/after state of the changed record. Use polling when your SIEM sits behind a firewall that blocks inbound connections, or when your compliance posture requires a strict pull-only model.