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

# Sync incident data into your data warehouse

> Join your incident data with the rest of your business data in BigQuery, Snowflake, Redshift, or your BI tool.

Sync your incidents, follow-ups, actions, alerts, and escalations into a data warehouse to report on them alongside your other data, like joining follow-ups to Jira tickets or incidents to revenue. There are three ways to do it:

* [**Fivetran**](#fivetran): a managed connector, with nothing to run yourself.
* [**Singer tap**](#singer-tap): our open-source exporter, which you run on your own infrastructure.
* [**Your own pipeline**](#build-your-own-pipeline): read the API directly, when you want incremental syncs or control over exactly what you load.

Whichever you choose, [How incident.io measures incidents](/insights/how-we-measure-incidents) explains what each timestamp and duration means, and which incidents are counted.

## Fivetran

[Fivetran's incident.io connector](https://fivetran.com/docs/connectors/applications/incidentio) loads your incident.io data into any Fivetran destination. It re-imports every table on each sync, so it picks up changes and deletions without any extra setup. Create an [API key](/admin/api-keys) for it, and follow [Fivetran's setup guide](https://fivetran.com/docs/connectors/applications/incidentio/setup-guide).

## Singer tap

Our [Singer tap](/integrations/singer-tap) exports your incident.io data to any [Singer target](https://www.singer.io/), including BigQuery, Snowflake, and Redshift. You run it yourself, on a schedule or from CI, and it exports everything on each run. See the [tap's documentation](https://github.com/incident-io/singer-tap/tree/master/docs) for configuration.

## Build your own pipeline

### What to sync

Each of these list endpoints supports an `updated_at` filter, so after an initial import you only fetch what changed:

| Data | Endpoint | `updated_at` filter | Max `page_size` |
| - | - | - | - |
| Incidents | [`GET /v2/incidents`](/api-reference/incidents-v2/list) | Date (`2026-10-01`) | 250 |
| Follow-ups | [`GET /v3/follow_ups`](/api-reference/follow-ups-v3/list) | Timestamp or date | 250 |
| Actions | [`GET /v3/actions`](/api-reference/actions-v3/list) | Timestamp or date | 250 |
| Alerts | [`GET /v2/alerts`](/api-reference/alerts-v2/list) | Timestamp or date | 50 |
| Escalations | [`GET /v2/escalations`](/api-reference/escalations-v2/list) | Date (`2026-10-01`) | 50 |

Use an [API key](/admin/api-keys) with the **View data** permission. Add the **View all incident data** permission to include private incidents.

### Initial import

Page through each endpoint with the largest `page_size` it allows:

```bash theme={null}
curl --get 'https://api.incident.io/v2/incidents' \
  --header 'Authorization: Bearer <YOUR_API_KEY>' \
  --data 'page_size=250'
```

Pass the `after` value from `pagination_meta` to fetch the next page. Stop when a page returns fewer records than your `page_size`. Don't wait for `after` to disappear, because the incidents endpoint can return an `after` value on its last page.

### Incremental syncs

From then on, fetch only what changed since your last sync:

```bash theme={null}
curl --get 'https://api.incident.io/v2/incidents' \
  --header 'Authorization: Bearer <YOUR_API_KEY>' \
  --data 'page_size=250' \
  --data 'updated_at[gte]=2026-10-01'
```

* **Treat every row as an upsert**, keyed on `id`. An incremental sync can return records you've already loaded.
* **Filter by the day of your last sync, not the time.** The incidents and escalations endpoints take a date, so `updated_at[gte]=2026-10-01` returns everything updated since the start of that day. Follow-ups, actions, and alerts also accept a full timestamp. Set it a few minutes before your last sync, so you don't miss a record that was being written as it ran.
* **Run an occasional full re-sync** to catch anything an incremental window missed.

<Warning>
  Listing incidents is limited to 60 requests a minute, lower than the rest of the API. At 250 incidents a page, that's
  still 15,000 incidents a minute. See [rate limits](/api-reference/introduction#rate-limits).
</Warning>

### Which incidents are included

The incidents endpoint leaves out test and tutorial incidents by default, along with incidents that were declined, canceled, or merged. To load those as well, filter on them explicitly with `mode` and `status_category`. See [Which incidents are counted](/insights/how-we-measure-incidents#which-incidents-are-counted).

### React to changes as they happen

If you need changes in your warehouse within seconds rather than on a schedule, subscribe to [webhooks](/integrations/webhooks). When one arrives, fetch the record's latest state from the API and upsert it, since webhooks can arrive out of order.