Customer.io Renamed Campaigns to Automations and People to Profiles. Change Your Playbooks, Not Your Code

On 24 August 2006 the International Astronomical Union settled on a definition of the word "planet", and Pluto failed one of the three tests. It orbits the Sun and it is round enough, but it has never cleared its neighbouring region of other objects. The resolution recorded that "Pluto is a 'dwarf planet' by the above definition and is recognized as the prototype of a new category of trans-Neptunian objects".

Nothing about Pluto changed. Same rock, same orbit, same moons. The label changed, and the category it sat in. That was enough to send textbooks, wall charts, planetarium scripts and every schoolroom mnemonic back for a rewrite. Twenty years on, the Library of Congress still keeps an explainer answering "Why is Pluto no longer a planet?", because people keep asking.

Customer.io did a smaller, tidier version of this on 15 July 2026. Six navigation labels changed. The thing underneath them did not, and that is the part worth your attention, because it splits your to-do list in two directions at once.

What actually changed on 15 July 2026

Six labels in the Customer.io navigation were renamed, and nothing else. The release note gives the full mapping:

You used to see	You'll now see
Campaigns	Automations
People	Profiles
Broadcasts > Newsletters	Broadcasts > One-time sends
Analysis	Reports
Deliveries & drafts	Message activity, with Sent and Drafts tabs
Activity logs	Profile activity

That is the whole list. Segments, workflows, broadcasts, objects and collections all keep their names. Broadcasts is still Broadcasts... only the Newsletters item beneath it became One-time sends.

Customer.io's stated reason is that the new words "better match how people think about marketing automation and messaging their audience". Fair enough. If you have ever watched a new starter hunt for where to build an automation and stall on the word "Campaigns", you know the problem the rename solves.

The sentence that is the whole story

One paragraph in that release note carries more weight than the table above it: "APIs and data don't change. Endpoints, field names, and identifiers keep their names. What we now call an automation is still a campaign in the API, and a one-time send is still a newsletter."

Read that again with your integration in mind. The screens your marketers look at now use one vocabulary. The payloads your code reads use another. Both are correct, and neither is going to be reconciled.

Customer.io also redirects the old URLs to the new ones, in the app and in the docs, so bookmarks and saved links keep working.

This is the right call. A vendor who renames a UI label costs you an afternoon of retraining. A vendor who renames an API object costs you an outage. Customer.io took the first bill and refused the second one on your behalf, because reconciling the two would break every integration built against it.

Proof the split is real, not marketing copy

You do not have to take the release note's word for it. The old names are visible in four places today.

The broadcast status response. Check the status of an API-triggered broadcast and the payload still comes back with "campaign_id": 5, on a docs page updated the same day as the rename. The operations are still called triggerBroadcast and broadcastStatus. That same page describes who gets the message as a "profile", so you can watch both vocabularies sit in one document.

The App API. The App API reference is generated from an OpenAPI file that Customer.io serves at journeys-app.json. That file still defines /v1/newsletters, plus the send, schedule and metrics sub-paths under /v1/newsletters/{newsletter_id}. The operation is listNewsletters, described as returning "a list of your newsletters and associated metadata". Search the file for "automation" or "one-time send" and you get nothing. If you have moved content management into the App API, your repo is already correct and should stay as it is.

Reporting webhooks. In the reporting webhooks specification, campaign_id is not merely present, it is a required property of the event data, sitting beside delivery_id and action_id. Example payloads show "campaign_id": 7. Anything downstream that keys on that field is safe.

Liquid. The Liquid syntax list still documents campaign.id, campaign.name, campaign.type and campaign.subscription_topic_ids, in both the latest and legacy Liquid versions. And here is the detail that tells you how long these layers have been out of step: the key for a person is still customer, not people and not profile either. Customer.io's own Liquid guide puts it plainly: "The {{customer.<attribute_name>}} key represents attributes associated with profiles."

Two lists: what to update, what to freeze

Everything you own now falls into one of two buckets. Get the split right and the rename is housekeeping. Get it wrong and you either mis-train your team or break your integration.

Update now: everything a human reads

These artefacts teach people where to click. Every one of them is now wrong in at least one label:

• Standard operating procedures and runbooks. Anything that says "go to Campaigns" or "open Activity logs" sends someone to a menu item that no longer exists by that name.
• Onboarding documents for new marketers, and any internal wiki page describing the workspace.
• Training decks and recorded walkthroughs. Screenshots are the expensive part, so start with the slides people actually use.
• Glossaries and naming conventions. If your team's glossary defines "newsletter", add "one-time send" beside it.
• Notes on where to find your reporting. Analysis is now Reports, so any page telling someone to check the workspace performance dashboard under Analysis needs a one-word edit.
• Client-facing enablement, if you run Customer.io for other people. They will see the new labels before they read your document.

Do not touch: everything a machine reads

Nothing in this list is affected by the rename, and editing any of it will break something that works:

• API integrations that post to /v1/campaigns/{broadcast_id}/triggers or /v1/newsletters/{newsletter_id}/send.
• Webhook consumers, ETL jobs and BI models keyed on campaign_id, newsletter_id, delivery_id or action_id.
• Liquid in your templates. Leave campaign.name alone... and while you are in there, the Liquid patterns that fail silently are a better use of an afternoon than a search-and-replace nobody asked for.
• CLI and MCP scripts. The cio api command and the MCP server both call the same unchanged endpoints, so the decision about which surface to use is unaffected and your existing scripts need no edits.
• Saved queries, dashboards and exports in your warehouse that reference the old field names.

One rule covers the whole thing. If a person reads it, update it. If a machine parses it, freeze it.

Brace for a long transition period

Through the rest of 2026 and into 2027, the words around you will disagree with each other, and some of that disagreement is inside Customer.io's own documentation.

Take the CLI getting-started page, updated on the day of the rename. One example prompt reads "List the active automations in my workspace". Another, a few lines below it, reads "Find people who haven't opened an email in 30 days". The Liquid guide, updated on 30 July 2026, has a heading called "Event-triggered automations" and a table describing data stored "temporarily in an automation, instead of a customer's profile". The navigation still carries an item called "Objects & non-people data". None of this is broken. It is what a vocabulary change looks like while it settles.

Third-party material will lag much further behind. Every tutorial, forum answer, agency blog post and Loom recording made before 15 July 2026 says Campaigns and People, and most of them will never be updated. Our own archive is in the same position: the guide to editing a live campaign says "campaign" throughout, and that word is still exactly right in the API it describes.

So give your team a translation key rather than a correction. One line on the wiki does it:

Automations = Campaigns = campaign in the API. One-time sends = Newsletters = newsletter in the API.

That single line turns every stale tutorial back into a usable one.

The opinion, stated plainly

The rename is good. Nielsen Norman Group has been making this argument for over a decade: "Descriptive category names that people understand are better than made-up words or internal jargon". Their usability studies find that people skip a label with weak information scent, even when it leads exactly where they want to go. "Automations" and "Profiles" describe what you get. "Campaigns" and "People" were inherited from an era of list-based email tools, and neither told a newcomer much.

But a rename you did not choose still hands you a bill, and this one is paid in documentation. Your screens now say one thing and your code says another, deliberately and permanently. Every SOP, deck and glossary you own drifted a little further from reality on 15 July, and nothing anywhere will tell you so.

Sinra's write-up on onboarding documentation puts the mechanism well: "Outdated documentation is a form of technical debt. It has the same properties: it accumulates gradually, it's invisible until it becomes a problem, and it's hard to pay down because no one remembers exactly what changed and why." The same piece names the property that makes this rename worth a calendar entry: documentation debt has no automatic alarm signal. Code that will not compile tells you immediately. A runbook pointing at a menu item that no longer exists by that name says nothing at all, and waits for the next new starter to follow it.

It also names why nobody fixes it. Documentation that belongs to everyone belongs to no one. Experienced people on your team stop noticing stale docs because they stopped reading them years ago.

So treat this as one scheduled repayment rather than a news item:

1. Give it an owner. One named person, not the team.
2. Set a date. A fortnight is plenty for a six-label change.
3. List the artefacts first, then edit them. SOPs, onboarding docs, decks, screenshots, glossary, dashboard notes, client enablement. The list is short and finite, which is the whole appeal.
4. Scope the find-and-replace to human-readable files only. Never point it at a repository, a template, or a warehouse model.
5. Write the code freeze down. "No integration changes are required for this rename" belongs in the ticket. Six months from now, an engineer will spot campaign_id in a payload and assume it is a leftover.
6. Brief the team once, out loud. A five-minute stand-up item lands better than a changelog nobody opens, and it is the moment to hand out the translation key.

If your workspace documentation was already thin before July, this rename is a decent excuse to fix the underlying problem rather than patch six words. That is the kind of work our Customer.io and email marketing training is built around. If you would rather not spend the fortnight yourself, tell us what you are dealing with.

Frequently asked questions

Q: What exactly did Customer.io rename in July 2026?

Six navigation labels, on 15 July 2026. Campaigns became Automations, People became Profiles, Newsletters (under Broadcasts) became One-time sends, Analysis became Reports, Deliveries & drafts became Message activity with Sent and Drafts tabs, and Activity logs became Profile activity. Nothing else in the product was renamed.

Q: Did the Customer.io API change when Campaigns became Automations?

No. The release note states that APIs and data don't change, and that endpoints, field names and identifiers keep their names. What the interface now calls an automation is still a campaign in the API, and a one-time send is still a newsletter. No integration work is required.

Q: Is a "one-time send" still a newsletter in the API?

Yes. The OpenAPI file behind the App API reference still defines /v1/newsletters and its send, schedule and metrics sub-paths. The operation is named listNewsletters and described as returning "a list of your newsletters and associated metadata". The words "one-time send" appear nowhere in it.

Q: Do my old bookmarked links and documentation paths still work?

Yes. Customer.io redirects the old paths to the new ones automatically, both in the app and in its documentation, so saved links and bookmarks resolve without any action from you. Some docs pages still link to older paths themselves, which is exactly what those redirects are for.

Q: My webhook and reporting data still say campaign_id. Is that a bug?

No, it is the documented behaviour. In Customer.io's reporting webhooks specification, campaign_id is a required property of the event data, alongside delivery_id and action_id, and example payloads show values like "campaign_id": 7. Anything downstream that reads that field should be left as it is.

Q: Do I need to change my Liquid, CLI or MCP scripts?

No. The Liquid syntax list still documents campaign.id, campaign.name, campaign.type and campaign.subscription_topic_ids in both Liquid versions, so those keys keep working. The CLI and the MCP server call the same unchanged endpoints, so scripts written before 15 July 2026 need no edits.

Q: Which UI areas do Reports, Message activity and Profile activity replace?

Reports replaces Analysis, Message activity replaces Deliveries & drafts (now split into a Sent tab and a Drafts tab), and Profile activity replaces Activity logs. The underlying screens and data are the same, so saved reports and dashboards are unaffected. What needs editing is any document telling someone where to find them.

Q: Why did Customer.io rename these labels at all?

To match the words people already use. The release note says the new labels better match how people think about marketing automation and messaging their audience. That matches long-standing usability advice from Nielsen Norman Group: descriptive names people already understand beat made-up words or internal jargon, because users skip labels with weak information scent.

Q: Will Customer.io eventually rename campaign in the API too?

Nothing in the documentation suggests it. The release note commits to endpoints, field names and identifiers keeping their names, with no deprecation notice and no timeline attached. Plan on the divergence being permanent rather than waiting for a second migration, and don't pre-emptively rename anything in your code.

Q: Is the word "people" gone from Customer.io entirely?

No, only the navigation label. The Liquid key for a person is still customer, the docs navigation still has an item called "Objects & non-people data", and docs pages updated after 15 July 2026 still use "people" in ordinary prose. Profiles is now the label in the interface, not a ban on the word.

Q: Did segments, workflows or broadcasts get renamed?

No. The mapping table in the release note is the complete list, and it covers six items. Broadcasts is still Broadcasts, and only the Newsletters item beneath it was renamed. Segments, workflows, objects, collections and message channels all kept their names.

Q: How should I brief my team and my clients on this?

Give them a translation key rather than a correction: Automations = Campaigns = campaign in the API, One-time sends = Newsletters = newsletter. That one line makes every pre-July tutorial and internal document usable again while you work through updating them. Say it out loud once in a stand-up, then put it at the top of the wiki.

Q: How do I tell whether one of my integrations is affected at all?

Ask whether it reads a label or a field. The release note's commitment covers endpoints, field names and identifiers across the board, not just the App API. So anything addressing Customer.io by identifier is unaffected: Track API calls, reporting webhooks, Liquid keys, CLI and MCP scripts, warehouse models. If the old word only appears on a screen or in a document a person reads, that is the thing to update.

Sources

• New names for familiar parts of Customer.io. Customer.io Docs, released 15 July 2026.
• Format API-Triggered Broadcasts. Customer.io Docs, updated 15 July 2026.
• App API reference and its OpenAPI file. Customer.io Docs, accessed 3 August 2026.
• Reporting webhooks reference. Customer.io Docs, accessed 3 August 2026.
• Liquid syntax list. Customer.io Docs, updated 10 July 2026.
• Personalize messages with liquid. Customer.io Docs, updated 30 July 2026.
• Get started with the Customer.io CLI. Customer.io Docs, updated 15 July 2026.
• 5 Tips for Avoiding Confusing Category Names. Hoa Loranger and Taylor Dykes, Nielsen Norman Group, 15 December 2013, last reviewed 11 October 2024.
• Developer Onboarding: The Real Cost of Outdated Docs. Sinra, 4 June 2026.
• IAU 2006 General Assembly: Result of the IAU Resolution votes. International Astronomical Union, 24 August 2006.
• Why is Pluto no longer a planet?. Library of Congress, published 19 November 2019, updated 25 February 2025.