Iterable is a growth marketing and customer engagement platform. It enables brands to create, execute and optimize campaigns across email, push, SMS, in-app and more with unparalleled data flexibility.
|Data blocking||check||Column level|
|Fivetran data models||check||Get the models: source / transform|
Follow our step-by-step Iterable setup guide to connect Iterable with your destination using Fivetran connectors.
This schema applies to all Iterable connectors.
EVENT table contains information of following events:
- Custom Event
- Email Send
- Email Open
- Email Click
- Email UnSubscribe
- Email Subscribe
- Email Bounce
- Email Complaint
- Hosted Unsubscribe Click
- InApp Open
- InApp Click
- Inbox Message Impression
- Inbox Session
- Push Send
- Push Bounce
- Push Open
- SMS Click
- SMS Send
- SMS Bounce
- SMS Received
- Web Push Send
LIST_USER_HISTORY table is the only way to join the
Excluding the table from the sync may lead to data discrepancy.
We capture events from Iterable using webhooks and the Events API, then write them to the destination.
We use the event data returned by the webhooks for data integrity. The event data from webhooks contains more fields than the data returned by the API. We retain this data for 30 days to be re-synced if needed.
EVENT table is the main table that contains all the fields we receive from the Events API.
EVENT_EXTENSION table serves as an extension to the
EVENT table. We store any additional fields we receive from the webhooks in the
We append the newly synced data to the end of a table. We add updates to the table as new rows and don’t update existing rows. The following tables are append-only:
During syncs, we override the event data returned by the Events API with the event data from the webhooks before writing the data into the destination tables.
When you trigger a re-sync, we first fetch all the historical data from the Events API and then fetch event data from the webhooks for the past 30 days. We then override the event data returned by the Events API of the past 30 days with the event data from the webhooks before writing the data into the destination tables.
NOTE: You may observe a few missing fields in the destination tables because the event data from webhooks contain more fields than the Events API data.