Ellipse Gradient for Header

Customer.io Integration Guide

Connect Customer.io People, Events, campaigns, and messaging activity with enterprise systems through REST APIs, batch ingestion, and selected webhook-style outbound requests.

Customer.io integration options at a glance

Customer.io primarily integrates through its Track API and App API. The Track API supports People, profile attributes, Events, deletions, and batch-style ingestion, while the App API provides selected access to Campaigns, Segments, Broadcasts, and related application resources. Customer.io also supports webhook-style outbound HTTP requests in selected workflows and integration features, rather than as a universal notification stream. Martini can consume these REST APIs, expose an API endpoint for supported Customer.io webhooks, schedule reconciliation workflows, paginate through responses, and map data into downstream applications. Site IDs, API keys, App API keys, and data-center-specific endpoints can be maintained in secure environment configuration.

Integration pointSupported by Customer.io?Common use casesHow Martini supports it
REST APIsYesCustomer.io's Track API manages People, attributes, Events, deletions, and batch-style ingestion. The App API supports selected Campaigns, Segments, Broadcasts, and related application resources.Martini can consume both Customer.io REST API surfaces from workflows, transform requests and responses, and apply business rules around validation, pagination, and retries.
Webhooks / outbound callbacksLimitedSelected Customer.io workflows and integration features can send outbound HTTP requests for campaign, customer, or messaging-related activity.Martini can expose a REST API or workflow trigger to receive supported requests, validate payloads, enrich data, and route it to downstream systems.
Bulk / async / batch APIsYesThe Track API supports batch-style ingestion for People and Events, subject to endpoint, payload, and usage constraints.Martini can assemble batches, control concurrency, process partial failures, and retry eligible responses without resubmitting invalid data unnecessarily.
AuthenticationYesThe Track API uses a site ID and API key, commonly with HTTP Basic Authentication. The App API uses an App API key as a bearer token.Martini can keep credentials, data-center-specific base URLs, and environment settings in secure secrets or configuration rather than workflow mappings or source code.
Scheduled synchronizationYesScheduled reconciliation can retrieve Customer.io data when webhook coverage does not include the required object or event.Martini scheduler-triggered workflows can maintain timestamps, cursors, or identifiers, paginate through results, and write synchronized data to target systems.
GraphQL APIsNot confirmedNo official Customer.io GraphQL API was confirmed in the supplied research.Martini should use the documented Customer.io REST APIs instead of assuming GraphQL support.
SOAP APIsNoNo official Customer.io SOAP API was identified.Martini can use REST-based integration patterns for Customer.io and connect SOAP-capable downstream systems separately when required.
File / attachment APIsNot confirmedNo general-purpose Customer.io file import, export, or attachment API was confirmed as a primary integration mechanism.Martini should not model Customer.io as a file-based integration unless a specific product feature is separately verified.

How Customer.io exposes data and business events

Customer.io REST APIs

Customer.io's primary integration interface consists of the Track API and App API. The Track API handles People, attributes, Events, deletion, and batch-style ingestion, while the App API covers selected application-level resources such as Campaigns, Segments, and Broadcasts.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates against the appropriate Customer.io API surface, retrieves or submits data, maps the payload to a canonical model, applies validation and business rules, and records outcomes for monitoring and retry.

Implementation sequence

Select the Track API or App API based on the resource
Load the data-center-specific endpoint and credentials from secure configuration
Retrieve or construct the Customer.io request
Paginate responses when the endpoint returns multiple pages
Map and validate People, Events, or application resources
Apply business rules and idempotency controls before submission or persistence

Customer.io Webhooks

Customer.io supports webhook-style outbound HTTP requests in selected workflows and integration features. Coverage depends on the product and configuration and should not be treated as universal change notification for every object or event.

Martini implementation pattern

Martini implementation pattern: expose a controlled REST API endpoint or workflow trigger, validate the incoming request according to the configured Customer.io webhook security model, acknowledge promptly, and send longer processing to an asynchronous workflow when appropriate.

Implementation sequence

Receive the supported Customer.io webhook request
Validate authentication, signature, structure, and required fields
Apply replay protection and create a correlation identifier
Transform and enrich the payload with downstream data
Route the result to CRM, support, notification, or data systems
Return an appropriate response and record processing status

Customer.io Batch Ingestion

The Track API provides batch-style operations for profile and event ingestion. Batch processing is useful for synchronizing larger volumes but remains subject to payload size, endpoint, rate, and usage constraints.

Martini implementation pattern

Martini implementation pattern: collect eligible People or Events, build bounded batches, submit them through the Track API, isolate invalid items where response details permit, and retry only transient failures with backoff.

Implementation sequence

Retrieve changed source People or Events
Normalize identities, event names, and timestamps
Partition data into Customer.io-compatible batches
Submit each batch through the Track API
Separate validation failures from transient API failures
Persist batch results and retry eligible failures

Common Customer.io integration patterns

Pattern 1: Synchronize CRM contacts to Customer.io People

When to use this pattern

Use this pattern when Salesforce, HubSpot, or another source system owns customer profile and lifecycle data while Customer.io manages behavioral messaging. A scheduled workflow can identify changed contacts and keep Customer.io attributes aligned.

Integration direction
Salesforce
Martini
Customer.io
Example Mapping
Customer.io FieldCanonical FieldTarget Field
Contact.IdpersonIdPeople.id
EmailemailAddressPeople.email
LifecycleStagelifecycleStagePeople.lifecycle_stage
ConsentStatusmarketingConsentPeople.consent_status
Martini implementation pattern

Martini retrieves changed contacts, normalizes identifiers and optional attributes, validates consent and required identity fields, and sends upsert-oriented profile updates through the Track API. The workflow records source versions or timestamps, retries temporary failures, and routes invalid profiles for correction.

Martini capabilities used
  • workflows
  • scheduler triggers
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 2: Send commerce events to Customer.io

When to use this pattern

Use this pattern when commerce or billing systems need to trigger lifecycle communications for purchases, renewals, abandoned carts, deliveries, or payment failures.

Integration direction
Shopify
Martini
Customer.io
Example Mapping
Customer.io FieldCanonical FieldTarget Field
Order.ideventIdEvent.identifier
Order.customerIdpersonIdEvent.personId
Order.statuseventNameEvent.name
Order.totalorderValueEvent.order_value
Martini implementation pattern

Martini consumes source events or retrieves changed transactions, applies stable event naming and identity rules, enriches the payload with customer and product data, and submits Events through the Track API. A persistence record prevents duplicate processing and transient failures are retried with bounded backoff.

Martini capabilities used
  • event-driven workflows
  • API consumption
  • data transformation
  • business rules
  • idempotency
  • retry handling

Pattern 3: Route Customer.io webhook activity to enterprise systems

When to use this pattern

Use this pattern when a selected Customer.io campaign action or messaging event must update a CRM, create an operational task, notify a team, or be recorded in a data platform.

Integration direction
Customer.io
Martini
Salesforce
Example Mapping
Customer.io FieldCanonical FieldTarget Field
person.idcustomerIdContact.ExternalId
event.typeengagementTypeContact.ActivityType
campaign.idcampaignIdCampaignActivity.CampaignId
occurred_atactivityTimestampCampaignActivity.Timestamp
Martini implementation pattern

Customer.io sends a supported webhook request to a Martini API. Martini validates the request, applies replay and duplicate controls, enriches the event if needed, and routes it to Salesforce or another target. Invalid payloads are rejected or quarantined, while downstream failures are retried asynchronously.

Martini capabilities used
  • API exposure
  • workflow triggers
  • payload validation
  • data mapping
  • conditional routing
  • asynchronous processing

Pattern 4: Reconcile Customer.io data with a warehouse

When to use this pattern

Use this pattern when webhook coverage is incomplete or analytics requires periodic extracts of People, Events, Segments, Campaigns, Broadcasts, or Messages.

Integration direction
Customer.io
Martini
Snowflake
Example Mapping
Customer.io FieldCanonical FieldTarget Field
idsourceIdcustomer_io_id
attributesprofileAttributesperson_attributes
nameresourceNamecampaign_name
updated_atlastChangedAtupdated_at
Martini implementation pattern

A scheduled Martini workflow calls the appropriate Customer.io API, follows pagination, transforms flexible attributes into governed warehouse structures, and writes validated results to Snowflake. A checkpoint based on a timestamp, cursor, or source identifier supports restartability, while failed pages or rows are isolated for retry.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination orchestration
  • data mapping
  • database integration
  • monitoring and error handling

Applications commonly integrated with Customer.io

Customer.io can participate in customer-data, behavioral messaging, analytics, and operational notification architectures. The exact object and event coverage should be validated for each application and Customer.io product configuration.

Application Scenario Direction Martini Pattern
Salesforce Synchronize contacts, lifecycle stages, and selected engagement activity with Customer.io People and Events. Salesforce → Martini → Customer.io A scheduled Martini workflow retrieves changed Salesforce records, maps identity and lifecycle attributes, validates required values, and calls the Customer.io Track API. Selected Customer.io webhook activity can be routed back through a Martini API to update Salesforce.
HubSpot Coordinate contact attributes and behavioral activity when Customer.io is used for lifecycle messaging alongside HubSpot. HubSpot → Martini → Customer.io Martini retrieves changed HubSpot contacts, normalizes attributes and consent fields, and upserts People through the Track API. A separate workflow can process selected Customer.io webhook requests for downstream activity updates.
Segment Forward behavioral events and profile data into Customer.io for audience activation and messaging. Segment → Martini → Customer.io Martini receives or retrieves Segment-delivered event data, applies canonical event naming and identity rules, and submits People or Events to the Track API with retry and duplicate controls.
Shopify Send customer, order, subscription, and product activity to Customer.io for transactional and lifecycle communications. Shopify → Martini → Customer.io Martini consumes Shopify events or API results, maps customer identity and commerce attributes, applies event-specific business rules, and sends profile updates or Events to Customer.io.
Snowflake Centralize Customer.io customer, event, and messaging data for analytics, reporting, and reconciliation. Customer.io → Martini → Snowflake A scheduled Martini workflow retrieves available Customer.io data through the relevant API, handles pagination and checkpoints, transforms responses into warehouse-oriented structures, and writes validated data to Snowflake.
BigQuery Combine Customer.io behavioral and messaging data with broader product and marketing analytics. Customer.io → Martini → BigQuery Martini periodically extracts supported Customer.io resources, converts flexible People attributes and Events into governed schemas, and loads them into BigQuery with checkpointing and error isolation.
Slack Notify internal teams about selected campaign, delivery, or operational events. Customer.io → Martini → Slack Customer.io sends a supported webhook request to a Martini REST API. Martini validates and enriches the payload, applies routing rules, and calls Slack for the appropriate channel or notification format.
NetSuite Use customer, order, or subscription information to trigger Customer.io lifecycle communications. NetSuite → Martini → Customer.io Martini retrieves changed NetSuite data, maps customer and transaction attributes to Customer.io People or Events, and records submission status for retryable and permanent failures.

How to build a Customer.io integration in Martini

Objective

Configure the Customer.io API surface, data-center-specific base URL, and credentials required for the workflow.

Instructions in Martini

  • Choose the Track API for People and Events or the App API for selected application resources
  • Store site IDs, API keys, App API keys, and endpoint configuration in Martini secrets or secure environment configuration
  • Keep credentials out of mappings, request bodies, logs, and source code

Objective

Select a trigger that matches the synchronization or event requirement.

Instructions in Martini

  • Use a scheduler for reconciliation and incremental synchronization
  • Expose a Martini REST API or workflow trigger for supported Customer.io webhook requests
  • Use an upstream application event when Customer.io data is being submitted

Objective

Obtain Customer.io data or accept a supported outbound request without assuming universal event coverage.

Instructions in Martini

  • Call the appropriate Track API or App API resource
  • Receive and validate selected Customer.io webhook-style requests
  • Handle pagination and preserve source timestamps, cursors, or identifiers where available

Objective

Coordinate API calls, enrichment, routing, and persistence through a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, transformation, submission, and status handling into clear workflow stages
  • Enrich People or Events with data from approved enterprise systems when required
  • Use conditional routing for valid, invalid, retryable, and permanently failed results

Objective

Convert Customer.io payloads and source data into consistent internal and target models.

Instructions in Martini

  • Map People attributes, Event names, identifiers, timestamps, and consent fields
  • Normalize flexible attributes and preserve source identifiers
  • Validate required values and tolerate optional fields or schema variation

Objective

Protect synchronization quality through business rules, idempotency, and bounded processing.

Instructions in Martini

  • Use stable People identifiers and deterministic event identifiers where supported
  • Prevent duplicate submissions with persistence or checkpoint records
  • Apply rate, batch-size, and concurrency controls

Common Customer.io data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
PeopleCustomer or user profiles identified by an ID and enriched with attributes such as lifecycle, subscription, locale, or consent data.Salesforce, HubSpot, Shopify, NetSuite, data warehousesMartini maps source identities and attributes, validates required fields, and sends create or update operations through the Track API.
EventsBehavioral activity such as purchases, sign-ups, product activity, payment failures, or subscription changes.Customer.io campaigns, analytics platforms, CRM systems, data warehousesMartini applies canonical event names, timestamps, identifiers, and business rules before submitting events through the Track API.
SegmentsGroups of People defined by behavioral or attribute-based criteria for targeting and analysis.CRM platforms, analytics platforms, operational reporting systemsMartini uses the App API where supported, transforms segment data, and synchronizes selected membership or reporting information.
CampaignsAutomated messaging journeys triggered by events, attributes, or segment membership.CRM systems, reporting platforms, operational notification systemsMartini retrieves or processes supported campaign resources through the App API and routes selected activity through workflow rules.
BroadcastsOne-time or scheduled messages sent to a selected Customer.io audience.Reporting platforms, CRM systems, analytics warehousesMartini consumes supported App API resources, normalizes scheduling and status fields, and persists synchronization checkpoints.
MessagesEmail, push, SMS, or other communication instances generated by Campaigns and Broadcasts.Data warehouses, CRM systems, notification and reporting systemsMartini maps available message activity from APIs or supported webhook deliveries, applies privacy controls, and routes operational outcomes.

Authentication and security considerations

API credentials

Customer.io uses different credentials for its API surfaces. The Track API uses a site ID and API key, commonly with HTTP Basic Authentication, while the App API uses an App API key as a bearer token.

Secure configuration

Martini should store site IDs, API keys, App API keys, and data-center-specific base URLs in secure secrets or environment configuration. Credentials should not be embedded in mappings, request bodies, or source code.

Privacy controls

Customer.io may process names, email addresses, behavioral Events, device information, and messaging preferences. Use least-privilege credentials, controlled logging, secure transport, and suitable retention policies.

Webhook protection

For supported webhook requests, Martini should validate the authentication or signing mechanism documented for the specific Customer.io feature, reject malformed payloads, and apply replay protection where appropriate.

Operational considerations for Customer.io integrations

Rate limits and batching

Customer.io usage is subject to endpoint-specific limits. Handle HTTP 429 responses, apply bounded backoff, avoid uncontrolled parallelism, and use Track API batch operations where appropriate.

Pagination and checkpoints

Do not assume a single response contains all People, Segments, Campaigns, or Messages. Paginate until completion and store timestamps, cursors, or source identifiers when available.

Idempotency and ordering

Retries can duplicate submissions, and asynchronous Events may arrive out of order. Use stable identifiers, persistence records, event timestamps, and duplicate detection rather than relying on network arrival order.

Schema changes

Flexible People attributes can produce inconsistent schemas. Establish naming and typing conventions, validate required fields, and make mappings tolerant of optional attributes.

Testing and monitoring

Test authentication, pagination, batch boundaries, webhook validation, partial failures, and rate-limit behavior. Capture correlation data and response details without exposing personal data, and monitor workflow logs and retry queues.

Why use Martini instead of scripts or point-to-point integrations?

Orchestration beyond a script

Martini coordinates Customer.io API calls, webhook reception, scheduled reconciliation, enrichment, transformations, business rules, and downstream writes in reusable workflows.

Maintainable integration logic

Mappings, validation, routing, credentials, and error handling can be separated into managed integration assets instead of being distributed across point-to-point scripts.

Reliable operations

Martini supports controlled batching, retries, checkpointing, asynchronous processing, monitoring, and failure isolation for enterprise synchronization workloads.

API-led architecture

Martini can consume Customer.io REST APIs and expose a controlled REST API façade for supported Customer.io webhook requests or downstream consumers without requiring a dedicated vendor connector.

Frequently asked questions

How can Customer.io be integrated with enterprise systems?

Customer.io can be integrated primarily through its Track API and App API, which provide REST-based access to People, Events, Campaigns, Segments, Broadcasts, and related resources. Selected Customer.io workflows and integration features can also send outbound webhook-style HTTP requests. Scheduled workflows support reconciliation when universal change notifications are not available.

Can Martini integrate with Customer.io?

Yes. Martini can consume the Customer.io Track API and App API, submit People and Events, retrieve supported application resources, and receive selected Customer.io webhook requests through a Martini REST API or workflow trigger. No native Martini Customer.io connector was verified.

Do I need a connector to integrate Customer.io with Martini?

No. A dedicated Customer.io connector is not required. Martini can use Customer.io's confirmed native integration mechanisms, including REST APIs, batch-capable Track API operations, selected webhook-style requests, and API-key-based authentication.

Is there any extra Lonti cost to integrate Customer.io with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Customer.io. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Customer.io, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Customer.io APIs should an integration use?

Use the Track API for People, profile attributes, behavioral Events, deletions, and batch-style ingestion. Use the App API for selected administrative and application-level resources such as Campaigns, Segments, and Broadcasts. Customer.io REST APIs are the primary documented integration mechanism; no official GraphQL or SOAP API was confirmed.

Are Customer.io webhooks available for enterprise workflows?

Customer.io supports webhook-style outbound HTTP requests in selected workflows and integration features. Coverage is product- and event-dependent, so these requests should not be treated as a universal notification stream. Martini can expose an authenticated REST endpoint to receive and process supported requests.

How should synchronization and data transformation be handled?

Martini can use scheduled workflows, pagination, source timestamps, cursors, or identifiers to reconcile Customer.io data. Mappings can convert People attributes and Events into canonical models, while business rules validate consent, identity, event naming, and required fields before data is sent to or retrieved from Customer.io.

How does Martini handle Customer.io errors, retries, and duplicates?

Martini workflows can distinguish rate-limit, timeout, and temporary server failures from authentication, validation, and malformed-payload errors. Bounded retries with backoff, batch controls, stable identifiers, checkpoints, and persistence of processed events help reduce duplicate submissions and make failures observable. Martini can also expose an API façade for downstream systems or webhook consumers.

Related Martini documentation

Martini APIs

Workflows

Security

Operations

Connect Customer.io with your enterprise systems

Use Martini to build maintainable Customer.io integrations around REST APIs, selected webhook-style requests, scheduled synchronization, secure configuration, and reliable workflow orchestration.

EXPLORE MARTINI
BOOK A DEMO