Destinations overview
UpdatedHow it works
A destination is the place you want to send your data to, like analytics platforms, CRMs, support tools, advertising platforms, messaging platforms, and more. We reshape data from your sources to fit the shapes expected by your destination, so you can use your source data in any available destination.
Most destinations support all our normal data sources. In these cases, data travels from your source, through Customer.io, and then to your destination. Some destinations—clearly marked with Web in our catalog—only support our JavaScript client. In these cases, data travels directly from your source to the destination, bypassing Customer.io.
We also have data warehouse destinations. Unlike other integrations, where data travels from your source to destination in real-time, data warehouse destinations send data in batches.
These destinations are a specialized type of cloud connection, where source data goes through Customer.io, where we transform the data and send it in batches to tables in your database. See our data warehouse destinations for more information.
Pipelines)) subgraph Destinations d(Your CRM) e(Your analytics
platform) f(Customer.io
Journeys) end a-->|JS integration|c b-->|Go, Python, or
Node integration|c c-->|Send website and
server-side data|d c-->|Send website source only|e c-->|Send website and
server-side data|f linkStyle 0,3 stroke-width:2px,fill:none,stroke:#AF64FF linkStyle 1 stroke-width:2px,fill:none,stroke:#00ECBB linkStyle 2,4 stroke-width:2px,fill:none,stroke:#0597AD
Set up a Destination
The steps involved in configuring your destination will change based on the specific destination and mode you enable. See an individual destination to learn more about the individual steps, and the information you’ll need, to connect a destination.
- Go to the Data Pipelines tab and click Connections.
- Click Add New under Destinations.
- Select the Destination you want.
- Configure your destination and click Continue.
- Select the mappings—the actions that you want to send to the destination. See Subscriptions below for more information.
You can change field mappings
In most cases, you’ll want to use default mappings with your destination. But, if you have a specialized use case and want to change the way we map fields to your destination’s events. See Mapping below for more information.
- (Optional) Select the sources that you want to connect to this destination. You can always connect sources to your destination later. You may not want to map sources to your destination
- Click Enable Destination.
You can check the Actions tab to see data as it comes in. This helps you make sure that your destination is set up correctly.
Actions
Your destination’s Actions tab shows recent data sent to the destination. You can find specific actions and look at the data as it’s sent to your destination. You might use this to troubleshoot specific source events.
When you set up a destination, you can check Actions to change the way we map source data to your destination—or just to better understand what data we’ll send to your destination by default.
Be careful when editing actions for your workspace
The Customer.io Journeys destination is how data gets into Customer.io—the people, events, and other data that you’ll use to send messages to your audience. It’s already configured with actionsThe source event and data that triggers an API call to your destination. For example, an incoming identify
event from your sources adds or updates a person in our Customer.io Journeys destination. to support incoming data from your sources. You can edit these actions if you want to change how we handle incoming data, but take care not to inadvertently break integrations with Customer.io.
Mapping source calls to your destination
Most destinations support Actions. Actions are how we map data from sources to your destination—the “trigger” for each request, and the fields we map to your destination.
In most cases, you’ll want to stick with the defaults. But, you might disable actions that you don’t care about in your destination. Or you might click and select Edit to change the way we map data to an action—this can help you better represent your model data in your destination if our default mappings don’t quite match your use case.
See our actions guide for more information.


API Call tester
On the API Call Tester tab, you can send calls to your destination to make sure that your integration works the way you expect. It may help to run test calls before you connect a source to your destination—so it’s easier to find your tests.
API calls are formatted to fit our source API. This gives you an opportunity to see how a call from your source(s) maps to your destination.
Test calls are populated with test data. Use the dropdown to select the kind of call you want to test.


Destination Overview
The destination Overview tab shows action volume and how many actions were completed or failed over a time frame. The overview helps you understand if your integration works as you expect, and can help you spot performance issues—failed actions or high latency.


Choosing a connection mode
When you add destinations, you may see some integrations with a Web option. These integrations:
- Only support our JavaScript client.
- Send data directly to your destination, bypassing Customer.io’s servers.
Where possible, we suggest that you use integrations in their normal, non-web iterations, but there are some reasons you might use a web integration. Sometimes, the web implementation supports operations that the destination’s normal, non-web implementation doesn’t.
Source Type | Destination | Web Destination |
---|---|---|
Website (JavaScript) | ||
Server (NodeJS, Go, Python) | ||
Mobile (iOS, Android, React Native, Flutter) | ||
Data Warehouse | ||
Customer.io |
Standard destinations
Under normal circumstances, your datasource sends data to Customer.io. We then transform and forward data to your downstream destinations. This keeps the size of injected scripts in your source integrations small and load times fast. Most importantly, this mode ensures that we keep a record of data sent to your destination, which can help you audit and troubleshoot issues with your destination.
Web destinations
Web destinations expect to receive data directly from your website without going through Customer.io’s servers. Often times, we have this mode to support services that don’t have public APIs for certain kinds of operations, and require us to load their SDK directly on your website to send data to them.
Since Web destinations don’t send data through Customer.io’s servers, you won’t see a record of actions sent to your destination. This can make it tricky to debug web destinations. If you need to debug or troubleshoot these destinations, you can try observing network calls in your browser console. If you need Customer.io’s help to troubleshoot web destinations, you may need to provide us with access to a staging environment where we can observe your integration.
In general, you probably only need to use web destinations if:
- The destination requires it. Some destinations only support web mode.
- You rely on destination features that require direct access to a service. For example, if you use Adobe Target and you want to load Adobe Target’s SDK (
at.js
) to take advantage of their A/B testing and personalization features, you’ll need to use the web destination. - You need to minimize latency between your site and your destination. For example, if you use a live chat destination, you might want to use the web version of the destination to ensure that your events pass to your live chat service as quickly as possible.
Retries: how we handle outages
If your destination suffers an outage, we’ll retry calls to the destination. We retry up to 14 times with an exponentially increasing delay between retries. The maximum retry window is about three hours.
We don’t retry when we get a definitive error, like a 400 or 403. Rather, we retry in the following situations:
- 429s: we’ve exceeded the destination API’s rate limit
- 5xx: the destination reported internal error
- Network errors: we were unable to establish network connection with the destination
- Other errors: errors that don’t produce status codes or are otherwise unrecognized
If you encounter errors and change your destination’s settings, or action settings for the destination, we’ll use the correct settings on the next retry. This makes it easy to fix problematic settings in your destination’s setup.