Source connector
Iterable connector
Iterable integration for databases, warehouses and BI tools
Cross-channel marketing automation and journeys. Datrise captures Iterable entities such as users, campaigns, journeys, message events, and experiments, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.
The Iterable API v1 authenticates with API key, JWT, incremental runs key on profileUpdatedAt (user profiles); startDateTime/endDateTime range on /api/export endpoints for events, and Iterable caps calls at 100 requests per second per project for most endpoints; the Export API is limited to 4 requests per minute per project.
Of the 5 objects, 4 sync as upserts keyed on the primary key and 1 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `iterable_users`) with a schema derived from the Iterable API rather than a flattened CSV, in any of the 43 supported destinations.
Datrise is in early access: pick a destination below to open the Iterable pipeline page, and join the waitlist to get the Iterable connector (Marketing) with guided onboarding.
What Iterable data Datrise extracts
Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.
| Object | Landing table | Sync mode |
|---|---|---|
| users | iterable_users | Upsert by primary key, incremental on updated-at |
| campaigns | iterable_campaigns | Upsert by primary key, incremental on updated-at |
| journeys | iterable_journeys | Upsert by primary key, incremental on updated-at |
| message events | iterable_message_events | Append-only, incremental by timestamp |
| experiments | iterable_experiments | Upsert by primary key, incremental on updated-at |
Iterable API: setup facts for the connector
Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.
| API | Iterable API v1 |
|---|---|
| Authentication | API key, JWT — Every request needs an `Api-Key` header tied to a project-scoped key (Standard, Server-side, Client-side, or Mobile type); JWT-enabled API keys add a short-lived signed-token layer on top of the static key for tighter scoping. |
| Pagination | none — Most endpoints return a single object or a full list with no page token; bulk history is instead chunked by `startDateTime`/`endDateTime` windows on the export endpoints. |
| Rate limit | 100 requests per second per project for most endpoints; the Export API is limited to 4 requests per minute per project |
| Incremental cursor | profileUpdatedAt (user profiles); startDateTime/endDateTime range on /api/export endpoints for events — Since February 2023 `profileUpdatedAt` no longer changes on a no-op update, so it is a reliable incremental cursor for the Users resource. |
| Webhooks | Yes — System Webhooks |
| Bulk export | Yes — Data Export API (/api/export/data.json, /api/export/userEvents) |
| Deletes detectable | No — Regular user deletes are hard deletes with no tombstone field; only GDPR-driven deletions are surfaced, via GET /api/users/forgotten returning the hashed emails of forgotten users |
What bites when replicating Iterable
- The Export API is capped at 4 requests per minute per project, ten times tighter than the general 100-requests-per-second limit, so a naive full-history export needs the date-range windows spread over many minutes to avoid HTTP 429s.
- Exports are capped at roughly 100 GB total with individual files up to 10 MB, so a large `startDateTime`/`endDateTime` window must be split into smaller ranges (commonly 28 days) to stay under the per-file ceiling.
- Ordinary `DELETE /api/users` calls leave no deletion record; a connector can only detect removed users by diffing full snapshots or by checking `GET /api/users/forgotten`, which lists only GDPR-forgotten users, not every delete.
- As of November 10, 2025, API keys passed in the query string or request body (instead of the `Api-Key` header) are subject to stricter rate limiting, which can silently throttle scripts written against older examples.
Popular destinations for Iterable
Choose a destination below to open the ready pipeline page.
- AAirtable
Relational spreadsheet destination for ops and go-to-market teams.
View pipeline - AAmazon Athena
Serverless SQL over S3 data lake tables.
View pipeline - AAmazon DynamoDB
Serverless key-value and document store on AWS.
View pipeline - AAmazon QuickSight
AWS serverless BI with SPICE and embedded analytics.
View pipeline - AAmazon Redshift
AWS petabyte-scale warehouse with Spectrum.
View pipeline - AAmazon S3 Data Lake
Object storage landing zone for parquet and snapshots.
View pipeline - AApache Superset
Open-source BI for SQL exploration, charts, and dashboard publishing.
View pipeline - AAzure Data Lake Storage
ADLS Gen2 object storage for analytics workloads.
View pipeline - AAzure Synapse
Microsoft analytics workspace with SQL pools.
View pipeline
Iterable connector FAQ
- What Iterable data does the connector extract?
- 5 objects: users, campaigns, journeys, message events and experiments. Each lands in its own table with types preserved; history-style objects (1: message events) load as append-only streams.
- Is the Iterable integration incremental?
- Yes. After the initial full load, every run reads only records changed since the last watermark (updated-at or event timestamp) and applies an upsert or an append depending on the object.
- Where can I load Iterable data?
- Into 43 destinations: relational databases, cloud warehouses, data lakes, spreadsheets and BI tools. Each Iterable → destination pair has its own page with the object-to-table mapping.
Related Marketing sources
Other sources in the same category, each with its own connector page.
Early access
Launch your Iterable pipeline with guided onboarding
Join the waitlist to get priority access for Iterable integrations with guided setup, schema-aware mapping, and production-grade incremental sync.