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.
Customer.io ships its own MCP. Here's the split.
Customer.io hosts a first-party MCP server — generally available, authenticated per user over OAuth, and built as a generic HTTP dispatcher over their full API rather than a fixed set of hand-written tools. That design gives it more reach into the account than Orbit's Customer.io tools have, and it is maintained by the people who run the API. If you want Claude working the account directly, connect it.
None of which changes what Orbit is for. API plumbing is not a defensible thing to compete on. The craft on top of it is: the render traps that only appear in Gmail, a pre-send gate that fails a build instead of mentioning a concern, dark-mode and inbox-client simulation, every Liquid branch in the template rendered rather than just the happy path, naming conventions that keep a program legible a year after the person who built it left, and a template brain derived from an email you already send. A server that can call every endpoint still cannot tell you whether the email is any good.
So run both, in the same Claude — Customer.io's server for reach into the account, Orbit for the judgement about what you put in it. One thing neither of us can do: Customer.io's API publishes no template CRUD, and that wall is the platform's, not the tooling's. The table below says so plainly.
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 — 79 lifecycle skills and 135tools 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 free — 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.
Does Customer.io have its own MCP server?
Yes. Customer.io hosts a first-party MCP server: generally available, authenticated per user over OAuth, and built as a generic HTTP dispatcher over their full API rather than a fixed set of hand-written tools. For working the account live it reaches further than Orbit's Customer.io tools do, and it is maintained by the people who run the API — connect it. What it does not carry is the craft on top: the render traps that only appear in Gmail, the pre-send QA gate, dark-mode and inbox-client simulation, Liquid branch coverage, naming conventions, and a template brain derived from an email you already send. One limit applies to both of us: Customer.io's API publishes no template CRUD, so neither server can push a reusable template. Orbit is not an official Customer.io product; it is an independent MCP that calls Customer.io's App API with the key you provide.
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.