Some of our best customers never open our app 

We recently closed a deal with a fast-growing infrastructure company. Their requirements were short: API-first access, a CLI (Command Line Interface), and the ability to work with Customer.io from the tools they were already in—Claude, Cursor, and Codex. No one on their team mentioned the UI.

That might sound like an edge case. It isn't.

A new kind of power user is emerging in the tools category: developers, technical marketers, and growth engineers who work almost entirely from the terminal or through AI coding agents. They don't toggle between browser tabs or log in to dashboards to build campaigns. Instead, they compose, manage, and iterate on customer messaging infrastructure the same way they handle everything else in their stack—with commands, integrations, and code.

Customer.io now fully supports this way of working. Our MCP integration and CLI enable you to use Customer.io without ever opening the app. And we think this is the beginning of something much bigger than a product feature.

Product-led growth used to follow a predictable arc. A marketer at a startup discovers your product, signs up for a free trial, and starts exploring the UI. The tool earns its place by being easy to use, and adoption grows from there.

That playbook still works. But it no longer describes where adoption starts.

Today, new businesses are being built and shipped faster than ever by people with varying technical backgrounds, using AI coding agents to deliver real products in days. When those products launch, they need customer messaging infrastructure from day one—confirmation emails, onboarding flows, transactional triggers. The decision about which messaging platform to use is made earlier, and increasingly it's made by whoever is writing the first lines of code.

That person isn't opening a browser to click around a free trial. They're asking their coding agent what tool to use, or they're typing a command in their terminal to initialize a project. If Customer.io isn't part of that moment, we're not in the conversation.

The Customer.io MCP server lets you connect Customer.io directly to AI tools like Claude, Cursor, and Codex. That means you can query customer data, build and update campaigns, manage segments, and trigger broadcasts—all from within your AI coding environment, without switching context.

The CLI puts the same capabilities at your fingertips from the command line. Developers can script workflows, automate campaign creation, version-control their messaging logic, and integrate Customer.io into their existing deployment pipelines.

Together, these two surfaces do something the UI was never designed to do: they make Customer.io feel native to the way engineers and technical marketers actually build.

Campaign infrastructure in code. Instead of clicking through a canvas to define a lifecycle flow, you describe it in natural language to your AI agent or express it as a series of CLI commands. The campaign becomes something you can express in code and rebuild from source—closer to how you handle the rest of your infrastructure than what most marketing tools allow.

Data access without leaving your environment. Technical marketers and growth engineers often need to pull audience segments, check engagement data, or validate that logic is working before pushing changes. With MCP, that happens inline—no tab switching, no exporting CSVs, no waiting for a dashboard to load.

Faster iteration at launch. For developers shipping new products, quickly configetturing transactional and lifecycle messaging configured quickly is a near-term requirement, not a nice-to-have. The CLI removes friction from initial setup and makes it easy to scaffold the patterns you need from the start.

It's tempting to frame MCP and CLI as purely developer tooling. But the sharper framing is about where work happens for anyone technical enough to use them.

Growth engineers, marketing engineers, and technical marketing managers increasingly live in the same environments as developers. They're using AI coding agents to build analyses, write queries, and prototype experiments. When their messaging platform speaks their language—when it has an MCP server and a CLI—it becomes part of their workflow rather than adjacent to it.

This matters for the quality of work they can do, not just the speed. When your customer messaging lives alongside your codebase, you can apply the same rigor—code review, staging environments, rollback—that you use everywhere else. That's a fundamentally different and better relationship with your messaging infrastructure than what most tools offer.

The deal we opened with—the team whose stated requirements were a CLI, API-first access, and the ability to work from Claude, Cursor, and Codex, with no mention of the UI—is one example, but the pattern is showing up across our fastest-growing customers. The companies building on AI infrastructure—and the companies adopting AI-native ways of working—want software that behaves like infrastructure. They want to access it through APIs, interact with it through CLIs, and now integrate it into AI agents through protocols like MCP.

The expectation is changing for what "modern software" means is changing. In that deal, having a CLI was a hard requirement—and it shaped the perception of where Customer.io sits relative to our competitors. For companies that care about how they build, that kind of access signals that the software belongs in their stack.That's not just about features—it's about whether a product feels like it belongs in the stack of a company that cares about how they build.

We think this is a preview of how more of our market will want to work. The preferences that next-gen companies have today tend to become the expectations that everyone has tomorrow.

If you want to try working with Customer.io through AI tools or the command line, here's where to start:

MCP server: Connect Customer.io to Claude, Cursor, Codex, or any MCP-compatible AI environment.

CLI: Install the Customer.io CLI and start managing campaigns, segments, and data from your terminal.

If you're building something interesting on top of these capabilities—or if your team has already moved to a terminal-first or agent-first workflow—we'd love to hear about it. Shoot us an email at product@customer.io.

What's the difference between the CLI and the MCP server? When should I use which?

The CLI (cio) is for developers and scripts—you type commands, it makes API calls, output is structured for piping into other tools and CI/CD pipelines. The MCP server is for AI agents like Claude Code or Cursor—they discover available tools dynamically and call them on your behalf. Same underlying API, different access patterns. Most teams end up using both: CLI for scripted workflows, MCP for interactive agentic work.

What can an agent actually do through the MCP server?

Create, read, update, and delete campaigns, segments, broadcasts, transactional messages, and customer profiles. Send messages across every channel we support: email, SMS, push, in-app, WhatsApp, Slack, and LINE. Read workspace metrics and audit logs. Effectively, anything our public API supports.

Are there things my agent can't do at launch?

A few things worth flagging. There's no atomic "save the whole campaign as a draft, then publish all changes at once" flow yet—edits go live as your agent makes them, so use a non-production workspace when iterating. The Workflows team is building more agent-friendly draft and atomic-publish patterns; those will ship after launch. Beyond that, the surface mirrors our public API.

Does the CLI auto-update when Customer.io ships new endpoints?

Yes. The CLI pulls the OpenAPI spec at startup and caches it. New endpoints become available automatically—no version bump required.

How do I install the CLI?

npm install -g cio, authenticate with a service account token, and you're ready. Full instructions are in the CLI docs.

How do I connect the MCP server?

Point your MCP-compatible client (Claude Code, Cursor, Claude Desktop, VS Code with Copilot, etc.) at our MCP server URL and authenticate via OAuth. Same connection model as our existing integrations—no new credentials to manage. Setup details in the MCP docs.

Can my agent delete campaigns or send messages to real customers?

Yes, with the permissions on the token or OAuth connection it's using. We strongly recommend creating a dedicated service account with scoped permissions for any agent—don't reuse your admin credentials. Treat agent access like any other privileged API access.

Is there an audit log?

Yes. Workspace audit logs cover all API actions, including those taken by agents and CLI sessions. Same logging model as any other API call.

My team is mostly marketers, not developers. Does this change anything for us?

Not directly. The UI isn't going anywhere—everything you do today still works. What this does is open the door for your engineering or growth-engineering counterparts to operate Customer.io from their environments instead of asking marketers to do it. If you don't have technical teammates working in Customer.io today, this won't change your day-to-day.

Is this only for technical companies?

The features are technical, but the value isn't limited to engineering-led companies. More work is happening through AI tools every quarter, even at "non-technical" companies. As your team starts using Claude, Cursor, or other agents for analysis, content, or operational tasks, having Customer.io natively reachable from those tools matters more than it does today.