Integration
MCP for Customer.io: read the program, proof the send.
You're in Customer.io, three campaigns and a stack of newsletters deep, and the question is the one no dashboard answers cleanly: which of these is actually working, and which segments have gone quiet? Orbit connects Claude to Customer.io's App API — the read-and-send interface behind your account — so you can ask that question in plain language and get it answered from live data. It reads your campaigns, your segments, your metrics. It sends a proof of the exact email you're about to ship. What it deliberately does notdo is pretend Customer.io's API can do something it can't, and there's one thing it can't. We'll get to it — plainly — below.
What Orbit does with Customer.io today.
Two kinds of "no" exist, and they matter. There's not possible via Customer.io's public API — a hard wall in the platform, nothing Orbit can build around. And there's not built yet— a gap on our side. On Customer.io there is no "not built yet" row. Every gap here is the API's, and we mark it as such.
| Job | Status | What that means |
|---|---|---|
| Read campaigns & newsletters | Native | Campaigns, newsletters, and broadcasts with per-item metadata. |
| Read segments | Native | Full segment list, so Claude can spot the stale and the shrinking ones. |
| Performance metrics | Native | Campaign metric series, read live rather than exported by hand. |
| Send a proof email | Native | Composed HTML sent inline to any address via the transactional send endpoint. |
| Auth check | Partial | No dedicated ping endpoint, so Orbit probes a cheap read to confirm the key works. |
| List / get templates | Not via API | Customer.io publishes no template/layout listing. Nearest read: your transactional messages and newsletters as the content inventory. |
| Create / update templates | Not via API | No public CRUD for reusable templates or layouts. The alternative is the inline-body proof send above. |
So the shape of Orbit on Customer.io is clear: it's a reading-and-proofing layer, not a template-push pipeline. If you want Claude to inventory the program, diagnose segments, and send you the exact email before it goes out, that's the whole job — and it does it well. Authoring reusable templates stays where Customer.io keeps it: inside the app.
How to connect it.
One credential, and you're reading live. Customer.io splits its API in two — a Track API for events and this, the App API, for reading the program and sending mail. Orbit only needs the App API, so there's one key to find.
App API key
customerio_app_api_keyA Bearer token, and the only secret Orbit stores for Customer.io. Find it in Customer.io under Account Settings → API Credentials → App API keys. Create one, copy it once, paste it into Orbit's config.
Region
customerio_regionus or eu, defaulting to us. This routes calls to the right base — api.customer.io for US accounts, api-eu.customer.iofor EU. Get it wrong and auth fails cleanly with a message telling you so; it won't silently read the wrong workspace.
Works with every ESP. Deepest on Braze.
Orbit reads and proofs across Customer.io, Iterable, Klaviyo, Mailchimp, and Salesforce Marketing Cloud through one normalized tool family. But the deepest single-platform integration is Braze, and some of what Orbit does there simply has no equivalent to port — because the concepts are Braze's own, not a feature we chose to withhold.
Content Blocks and Canvas are Braze constructs; there's no Customer.io object that maps to them, so the Braze-named tools stay Braze-named. That's the same honesty running through this whole page: Orbit doesn't invent parity where the platforms don't share it. See the full breakdown on the methodology page →.
Beyond the API.
The Customer.io connection is one slice of Orbit. The rest is platform-neutral and works the same no matter which ESP you plug in — 66 lifecycle skills and 99tools that don't care whose API is behind them:
Build the email, not just describe it
Compose copy, generate MJML that compiles to clean, client-safe HTML, then proof it straight into Customer.io's inbox test — the same pipeline whether you send through Customer.io or anywhere else.
Render and QA before it ships
Dark-mode checks, structural QA, accessibility linting — the gates that catch the broken render before a subscriber does. Platform-agnostic, because a mangled table cell looks the same in every inbox.
Do the lifecycle math
Sample-size, holdout design, RFM, LTV and payback — the calculators that turn "let's test it" into a test you can actually read the result of. None of them touch an ESP; all of them sharpen what you send through one.
Try it.
Orbit is a one-off purchase — $124.50 during the launch window, $249 after. One payment, every skill and tool included, no seats and no subscription. Paste your Customer.io App API key and Claude reads your program the same afternoon.
Frequently asked.
Can Orbit push email templates into Customer.io?
No — and that's a Customer.io limit, not an Orbit one. Customer.io's App API has no public endpoint for creating or updating reusable templates or layouts; that content is authored in-app. What Orbit does instead is send a fully-composed email inline through the transactional send endpoint, so you can proof the exact HTML to any address without leaving Claude.
What can Orbit actually read from Customer.io?
The program. Campaigns, newsletters, and broadcasts with their metadata; segments; and campaign performance metrics — all through Customer.io's App API, normalized into the same shape Orbit uses for every ESP. You can ask Claude which segments are stale, what's in your newsletter and broadcast history, or how a campaign is trending, and it reads the answer live.
How do I connect Customer.io to Orbit?
One credential: a Customer.io App API key (a Bearer token from Account Settings → API Credentials → App API keys). Paste it into Orbit's config, set your region to us or eu, and the read tools and proof send light up. The separate Track API isn't needed — one key, one client.
Is Customer.io the right ESP to run through Orbit?
If your team is happy authoring email inside Customer.io's own visual editor and wants Claude for reading the program, diagnosing segments, and proofing sends — yes, it's a strong fit. If your core workflow is generating and pushing HTML templates from outside the platform, Braze or Mailchimp will feel less constrained, because their APIs expose template CRUD that Customer.io's doesn't. Orbit tells you which side of that line you're on before you buy.
Does Orbit work the same across every ESP?
The read layer and the portable tooling — skills, MJML compilation, render and QA gates, the lifecycle calculators — work everywhere. Write depth varies by what each ESP's API allows, and Orbit never fakes parity: it's deepest on Braze, and it labels every capability as native, partial, or not-possible-via-the-API rather than pretending they're all equal.
Run a different platform?