Reference · built on requestConnectorMarketing, reviews & analytics

Customer.io

People, events, segments, broadcasts, and transactional sends from Customer.io, with signed reporting webhooks for message events.

Request accessPricing ↗

About

Customer.io is a messaging automation platform. A workspace holds people and their attributes, the events they trigger, segments, campaigns, broadcasts, newsletters, and transactional messages across email, SMS, push, in-app, and WhatsApp. Data enters through the Track API or the Pipelines API; sends and lookups go through the App API; message outcomes leave through reporting webhooks. US and EU workspaces use different hosts.

Through Fibric, an operator reads a person's attributes, segment membership, and message history, joins them with order and support records, and proposes an event, an attribute change, or a transactional send for your approval. Approved actions run once and leave a record of the reason and the undo path.

This is a reference listing. It documents what Fibric would read from Customer.io and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • People through the App API: attributes, segment membership, message delivery history, and subscription preferences
  • Campaign, broadcast, and newsletter metrics, plus per-link metrics, through the App API
  • Reporting webhooks for email, SMS, push, in-app, WhatsApp, Slack, and webhook messages: drafted, sent, delivered, opened, clicked, bounced, failed, and unsubscribed
  • Customer events for subscribed, unsubscribed, and subscription preferences changed
  • Collections, snippets, sender identities, and ESP suppression lists

Proposed actions

  • Target capability: propose a person attribute update through the Track API PUT customers call
  • Target capability: propose an event through the Track API POST events call, which can start or branch a campaign
  • Target capability: propose a transactional email, SMS, or push message through the App API send endpoints
  • Target capability: propose an API-triggered broadcast to a segment through the App API
  • Target capability: propose adding or removing a person from a manual segment through the Track API

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Trigger a shipping-delay message

    When the carrier shows no movement, the operator proposes a Track API event with the order and new estimate. Your campaign sends the message; the record shows who was told and when.

    With Stalled Shipment, ETA Notice

  • Suppress marketing after a complaint

    After a low score in your help desk, the operator proposes an attribute update so campaigns pause for that person until the callback closes.

    With Detractor Callback, Sentiment Spike

  • Reconcile bounces with the customer record

    Reporting webhooks deliver bounced and failed events. The operator matches them to the customer in your support tool and proposes a note or a contact correction.

    With Contact Drivers

  • Tell affected customers about an incident

    The operator drafts the audience from a segment and proposes an API-triggered broadcast with the incident details. You approve before it sends.

    With Outage Notice

Requirements

  • A Customer.io workspace and its region, which selects track.customer.io and api.customer.io for US or track-eu.customer.io and api-eu.customer.io for EU
  • A Track API key (site ID plus key) for writes to people and events, and an App API key for sends and reads
  • A reporting webhook configured under Data & Integrations > Integrations, with its signing key, for message events
  • Transactional messages and API-triggered broadcasts set up in the workspace before the operator can propose them
Authentication
Track API calls use HTTP basic authentication with your site ID and Track API key; App API calls use a Bearer App API key; both come from the workspace settings.

Limits

  • The App API allows 10 requests per second on most endpoints; API-triggered broadcasts are limited to 1 request every 10 seconds
  • Track API requests are capped at 32 KB each and 500 KB per batch, with 300 attributes per person and 1,000 bytes per attribute value
  • The Track API rate of 1,000 requests per second is a soft limit; exceeding it consistently can throttle or drop data
  • Reporting webhooks time out after 4 seconds; retries continue with exponential backoff for up to seven days

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Customer.io ↗

Questions and answers

Which API does the connector use for what?
The Track API (track.customer.io or track-eu.customer.io) writes people, events, devices, and manual segment membership with basic auth. The App API (api.customer.io or api-eu.customer.io) sends transactional messages, triggers broadcasts, and reads people, metrics, and message history with a Bearer App API key.
How are reporting webhooks authenticated?
Each request carries X-CIO-Timestamp and X-CIO-Signature. The signature is an HMAC-SHA256 of v0:<timestamp>:<body> using your webhook signing key. Compare it before trusting the payload. Deliveries time out after 4 seconds and retry with exponential backoff for up to seven days.
What are the size limits on the Track API?
32 KB per request and 500 KB per batch call. A person can hold 300 attributes, each value up to 1,000 bytes. The documented rate of 1,000 requests per second is not strictly enforced, but sustained overruns can be throttled or dropped.
Ask about Customer.io

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Customer.io through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy