# Connect Customer.io

You'll save visitors' answers to Customer.io attributes and use what you already know about each person to personalize your website.

Available on the Scale and Pro plans.

Connect Customer.io to save visitors' answers to their records, ready for your follow-up. You can also use an identified person's existing attributes and segments to show them relevant content on your website.

## Connect Customer.io

You'll need permission to edit your RightMessage project and two kinds of credentials from the same Customer.io workspace:

- The Tracking API **Site ID** and **API Key** let RightMessage write data.
- An App API key lets RightMessage look up people and read the segment catalog.

A project connects to one email platform or CRM at a time. Review where you use an existing connection before replacing it.

The connection uses `api.customer.io` and `track.customer.io` and has no region selector. If your workspace requires regional endpoints, check compatibility with RightMessage support before using it.

1. In Customer.io's API credentials area, obtain the Tracking API Site ID and key, then create or retrieve an App API key for the same workspace.
2. In RightMessage, open your project's settings and select **Integration**.
3. Under **Email platforms & CRMs**, select **Customer.io**.
4. Paste the Tracking key into **API Key** and its site identifier into **Site ID**.
5. Paste the App API key into **App Key**.
6. Click **Connect**.

![Customer.io connection form in RightMessage with the Site ID, API Key and App Key fields and Connect button highlighted](https://rightmessage.com/help/screens/integrations-customerio-connect.light.webp)

Check connection health in **Overview**. This reads segments with the App API key. You'll test the separate Tracking credentials when you save an answer below. Use **Save Changes** if you update credentials.

[Install the RightMessage snippet](https://rightmessage.com/help/everything-you-need-to-know-about-your-rightmessage-tracking-script) on your website and any redirect page you'll test.

## Recognize subscribers from email links

Use Customer.io's automatic `_cio_id` parameter so RightMessage can recognize people who click through to your site.

1. In Customer.io, open **Workspace Settings → URL Parameters**.
2. Choose **Settings** if parameters are already configured, or **Get Started** if they aren't.
3. Enable **Add \_cio\_id URL parameter**.
4. Send a new message to a test person with a tracked link to your website.
5. Check that the delivered link includes `_cio_id` and that redirects preserve it until the page with RightMessage loads.

Customer.io covers this setting in [Identify people](https://docs.customer.io/integrations/data-in/connections/javascript/legacy-js/identify). It affects new messages, not messages already in inboxes. RightMessage reads `_cio_id` directly, so you don't need Customer.io's JavaScript library for this method.

If you already use manually configured links, RightMessage also accepts `rm_cio`. For example, a link to [WorkForge](https://workforge.rightmessage.com) could be:

```text
https://workforge.rightmessage.com/solutions.html?rm_cio={{customer.id}}
```

Use your own page URL. `{{customer.id}}` supplies your assigned Customer.io person ID, which isn't necessarily the internal `cio_id`. The ID must exist and resolve for that recipient. Use `&rm_cio=` when the URL already has query parameters, and put it before any `#` fragment. Use one identity method per link rather than conflicting `_cio_id` and `rm_cio` values.

### Use the right person identifier

Customer.io has three identifiers, and they aren't interchangeable:

| Identifier | What it identifies                                                                        |
| ---------- | ----------------------------------------------------------------------------------------- |
| `email`    | The person's email. Configured and permitted email-based capture can create a new person. |
| `cio_id`   | Customer.io's internal person ID. The `_cio_id` link parameter carries it.                |
| `id`       | An ID assigned by your application or import. It can differ from the email and `cio_id`.  |

RightMessage strips a `cio_` prefix only when exactly 16 or 18 hexadecimal characters follow it. It leaves other custom-ID prefixes alone.

For non-email lookups, RightMessage tries `cio_id` first. It falls back to `id` when Customer.io reports a missing or malformed ID. Authentication, rate-limit, and upstream failures don't count as a missing person.

Writes choose the identifier type by its shape. Emails use `email`, 16- or 18-character hexadecimal values use `cio_id`, and other values use `id`. If your custom IDs look like internal hexadecimal IDs, ask support to review the exact path before enabling writes. A successful lookup through the `id` fallback doesn't change how a later write chooses its identifier type.

### If you use Customer.io's legacy tracking cookie

RightMessage can read the namespace's `id` cookie, normally `_cioid`. It doesn't use the anonymous `_cioanonid` cookie as a person ID, and it doesn't write Customer.io's cookie.

An explicit `rm_cio` or `_cio_id` URL value takes precedence. A remembered RightMessage identifier also takes precedence over the cookie. The generic `email` parameter is a fallback when no subscriber ID has been established, not a way to override a remembered person. Another device still needs its own identification.

## Choose what to sync

Use **Attribute** mapping for choice answers and segment groups. Enter the exact attribute name you want. Customer.io attributes aren't restricted to a predefined field catalog, and this connection has no separate native-field catalog.

> **Use attributes for question answers**
>
> The editor offers **Segments**, but that answer-sync mode sends a tag operation Customer.io rejects. Use **Attribute** instead. The separate **Add to segment** contact action can add someone to a manual segment when they sign up.

RightMessage reads the person's attributes and returned segment memberships. It doesn't expose `email` or `created_at` as ordinary custom fields. The segment picker offers manual/static segments, not data-driven segments.

For an Email question, **Contact action** offers **Create/Update contact** and **Add to segment**. Choose a manual segment if you want that signup destination. You don't need one to create a contact. Segment writes add the person to selected segments without removing previous memberships. Keep identification and appropriate consent enabled.

You can configure outgoing events with event properties as separate actions. The connection doesn't read event or purchase history for conditions, and it doesn't sync tags.

Outgoing string attribute values and event-property values are limited to 100 UTF-8 bytes, including strings inside arrays or objects. RightMessage truncates longer values. That's a byte limit, not a guarantee of 100 characters, so check the saved text before using these fields for long responses.

Follow [Map answers to contact fields and tags](https://rightmessage.com/help/synchronizing-contact-data-with-your-email-platform-or-crm), then publish the changes you want live. Customer.io processes writes asynchronously, so a new person may not be available immediately for a segment or event action.

## Check the connection

1. Choose an existing test person and note their email, assigned `id`, internal `cio_id`, and a distinctive attribute value.
2. Open their newly delivered identifying link in a fresh browser session. Use RightMessage's on-site debugger to check the identifier and person.
3. Outside debugger mode, submit a mapped answer on the live site. Check that the original Customer.io person received it.
4. In another fresh session, submit a new test signup. Check the person, mapped attributes, and any manual segment you selected.
5. Search Customer.io for unintended extra or email-less profiles as well as the person you expected.

If you find an extra or email-less profile, pause the affected action and contact support. Share a redacted example of the parameter name, identifier format, expected person, actual person, and action that created it. Don't send API keys, swap `id` and `cio_id` everywhere, or keep submitting the same form.

The field-update path guards against writing to a missing or email-less non-email identity. Contact creation, segment additions, and events use separate paths. That guard doesn't prevent every possible duplicate or shadow profile.

Debugger mode blocks external writes. When existing answers stay on the original person and new signups create only the intended person, your setup is working. If a check fails, [Verify an integration change](https://rightmessage.com/help/verify-an-integration-change) helps you separate connection, identification, and write problems.