Customer.io

Introduction

The Customer.io App for Flows enables you to connect your workflows to Customer.io, a messaging and customer engagement platform. This integration allows you to create and update people, track behavioural events, trigger journeys, send transactional email and push, and read your campaigns, broadcasts and segments, directly from your Flows without writing complex code. With this App, you can build automated workflows that keep Customer.io in sync with player and customer activity in real time, perfect for registration onboarding, behavioural campaign triggers, and transactional messaging.

What is Customer.io?

Customer.io is a customer engagement platform that stores a profile for every person, records the events they generate, and uses both to drive automated messaging journeys across email, push, SMS and in-app. Key features include:

• People profiles with unlimited standard and custom attributes
• Event tracking that triggers and branches campaigns
• Campaigns, API-triggered broadcasts and segments
• Transactional email and push with reusable templates
• Suppression and device management for compliance and mobile messaging

Getting Started

Prerequisites

Before using the Customer.io App, you will need:

• A Customer.io account on the EU data centre
• Your Track API Site ID and Track API Key
• An App API Key

Finding Your Credentials

1. Log in to Customer.io and go to Settings > Account Settings > API Credentials
2. Open the Track API Keys tab and copy the Site ID and the API Key — these are your siteId and trackApiKey
3. Open the App API Keys tab, click Create App API Key, name it, and copy the generated token — this is your appApiKey

Recommendation: the Site ID and Track API Key travel as HTTP Basic authentication, and the App API Key as a Bearer token. Keep all three secure — anyone holding them can read, message and delete every person in your workspace. The App API Key is shown only once when created, so store it before closing the dialog.

Region: this App is hardcoded to the Customer.io EU data centre. Credentials from a US workspace will return 401 on every stage.

Available Stages

Authentication

Customer.io splits its functionality across two APIs with two different credentials. The App handles this for you — the connection collects all three values once, and each stage uses the right pair. There is no OAuth, no token refresh and no expiry handling.

Track API — used by every stage that pushes data in: Create or Update Person, Identify Person, Track Event, Track Anonymous Event, Delete Person, Suppress and Unsuppress Person, Add or Update Device, Delete Device, Add to and Remove from Segment.

Authorization: Basic base64(siteId:trackApiKey)

Base URL: https://track-eu.customer.io/api/v1

App API — used by every stage that sends a message or reads data back: Trigger Broadcast, Send Transactional Email, Send Transactional Push, Look Up Person by Email, Get Person Attributes, and all four List stages.

Authorization: Bearer <appApiKey>

Base URL: https://api-eu.customer.io/v1

Create or Update Person

The Create or Update Person stage creates a person in Customer.io or updates an existing one, sending any attributes you want as a single JSON object. This is the stage to use on a registration event.

Input Parameters

Output

Usage Example

Important Notes

• The Payload field is your mapping layer. The left side of each pair is the attribute name in Customer.io, the right side is the data coming from your flow. When a different client names the same attribute differently, you edit this one field in their flow — nothing else changes
• Attributes are merged, not replaced. Sending {"vip_level":"gold"} later updates only that attribute and leaves the rest intact, so the same stage covers registration and every later profile update
• The Payload must be a valid JSON object. A trailing comma or an unquoted key returns a 400
• This stage supersedes Identify Person, which can only send an email address
• If your workspace identifies people by both id and email, sending a new id with an email that already belongs to someone does not create a duplicate — Customer.io updates the existing person and assigns them the new id instead. This is a common source of confusion when testing: reusing the same email with different generated IDs updates one person repeatedly, it does not create multiple people
• You can also set unsubscribed:true directly inside the Payload to suppress a person in the same call that updates their other attributes — this has the same effect as running Suppress Person separately, and can save a stage if you're already sending a Payload

Identify Person

The Identify Person stage creates or updates a person with an email address only. It is kept for flows already using it — new flows should use Create or Update Person.

Input Parameters

Output

Returns success, id and email.

Important Notes

• This stage calls exactly the same Customer.io endpoint as Create or Update Person — the only difference is that it can send nothing but the email address

Track Event / Track Anonymous Event

These stages record an event in Customer.io. Track Event attaches it to a known person; Track Anonymous Event records it with no person attached, for activity from visitors you have not identified yet.

Input Parameters

Output

Usage Example

Important Notes

• Events are accepted asynchronously. A success response means Customer.io queued the event, not that a campaign has fired — allow a few seconds before checking the person's Activity log
• Anonymous events can only trigger campaigns that do not target a person, so use Track Event whenever you have an ID

Delete Person / Suppress Person / Unsuppress Person

These three stages act on an existing person using their ID. Suppress stops all messaging while keeping the record; Delete removes the person entirely.

Input Parameters

Output

All three return success and the id you sent.

Important Notes

• Delete Person is permanent and takes the person's event history with it — there is no undo
• Suppress Person is the right choice for an unsubscribe or a GDPR objection: the person stops receiving messages but their history survives for reporting
• A suppressed person is silently skipped by every campaign. If messages stop arriving for one user and nothing looks wrong, check whether they are suppressed
• Deleting a person who does not exist still returns success — these calls are idempotent

Add or Update Device / Delete Device

These stages register or remove a mobile push token on a person, which is what makes push messaging possible for that user.

Input Parameters

Output

Add or Update Device returns success, id and deviceToken. Delete Device returns success and id.

Important Notes

• Push tokens rotate. Call Add or Update Device on every app launch rather than only at registration, or your push delivery will silently decay over time
• Call Delete Device on logout, otherwise the next person to use that handset receives the previous user's notifications

Add to Segment / Remove from Segment

These stages add or remove people from a manual segment in Customer.io.

Input Parameters

Output

Both return success and the segmentId you sent.

Important Notes

• Only manual segments can be edited through the API. A data-driven segment computes its own membership and the call will fail
• Person IDs that do not exist are ignored silently rather than returning an error, so a success response does not prove every ID landed

Trigger Broadcast

The Trigger Broadcast stage starts an API-triggered broadcast in Customer.io — the way to launch a Customer.io journey from a Flow.

Input Parameters

Output

Important Notes

• The broadcast must be created in Customer.io as an API-triggered broadcast. Triggering any other type returns 404, which reads like a wrong ID but is not
• The broadcast must also be live in Customer.io — a draft returns 404 as well

Send Transactional Email / Send Transactional Push

These stages send a one-off message rendered from a transactional template — receipts, password resets, shipping confirmations. They bypass campaigns entirely.

Input Parameters

Output

A delivery_id means queued, not delivered. Sending happens asynchronously — check Deliveries in Customer.io, or use a Customer.io webhook, if you need delivery confirmation.

Important Notes

• The template must be live. A draft template returns 400
• Send Transactional Push reaches only people who have a device registered through Add or Update Device. With no device on the profile the call succeeds and nothing arrives
• A suppressed person receives nothing, transactional messages included

Look Up Person by Email / Get Person Attributes

These read stages find a person or read back everything stored on one — useful for checking a sync worked, or for branching a flow on an attribute Customer.io holds.

Input Parameters

Output

results is an array. Flows cannot resolve array indexes, so add a Loop stage over the response if you need to read individual people out of it.

Important Notes

• The same email address can belong to more than one person if your workspace has been fed inconsistent identifiers, which is why this returns an array rather than a single record
• Get Person Attributes returns custom attributes alongside standard ones, so it is the quickest way to confirm a Create or Update Person payload landed as intended
• Get Person Attributes also returns cio_id, a permanent identifier Customer.io generates automatically and never changes. If you ever need to update a person's email or other identifier after it's been set, reference them using cio_<the cio_id value> in the ID field of another stage — this is the only way to change an identifier once it exists

List Campaigns / List Broadcasts / List Segments / List Transactional Messages

These four stages take no parameters and return everything of their type in the workspace. Their purpose is to find the IDs the other stages need.

Output

Each of these fields is an array. Flows cannot resolve array indexes — add a Loop stage over the response, or run the stage once by hand and copy the ID you need into the stage that consumes it.

Important Notes

• In practice these are run once during setup to collect IDs, not on every flow execution

Use Cases

1. Registration sync — a registration event fires Create or Update Person with the player's ID and a Payload mapping their registration fields onto your Customer.io attributes. Customer.io journeys take over from there.
2. Behavioural campaign triggers — call Track Event with first_deposit or kyc_verified and let Customer.io campaigns react, with no further logic in the Flow.
3. Profile enrichment over time — call Create or Update Person again whenever a player's tier, balance band or preferences change. Attributes merge, so each call only needs the fields that changed.
4. Transactional receipts — after a payment, Send Transactional Email with your receipt template and the player's ID as Identifier ID.
5. Launch a journey from a Flow — run List Broadcasts once to find the ID, then call Trigger Broadcast whenever your Flow's conditions are met.
6. Unsubscribe and GDPR handling — Suppress Person on an opt-out, Delete Person on an erasure request.
7. Mobile push lifecycle — Add or Update Device on every app launch, Delete Device on logout, then Send Transactional Push for time-critical alerts.

How to Test

1. Install Customer.io from the marketplace and create a connection.
2. Paste your Site ID, Track API Key and App API Key from Settings > Account Settings > API Credentials into the three connection parameters. They must come from an EU workspace.
3. Start with List Segments — it takes no parameters and needs nothing pre-existing, so it proves the App API Key works on its own.
4. Run Create or Update Person with id = flows-test-1 and payload = {"email":"[email protected]","first_name":"Jane","plan":"pro"}. Open People in Customer.io and confirm the person exists with all three attributes — this proves the Track API credentials work.
5. Run it again with payload = {"plan":"enterprise"} and confirm only plan changed while email and first_name survived. This is the merge behaviour.
6. Run Track Event with the same id and eventName = flows_test_event, then check the person's Activity log.
7. Run Get Person Attributes with that id to confirm the read path and the App API Key.
8. Clean up with Delete Person.

Each endpoint also carries a pink note in the Designer canvas with its own test recipe and example values.

Troubleshooting