Customer messaging tools that don't need engineers

Three emails, a push if they don't open, skip anyone who already upgraded. You could have it built by Thursday. Instead it's a ticket, a sprint, and two weeks to find out the subject line was wrong.

Customer messaging covers two jobs: the marketing campaigns you send to a segment, and the product notifications you send to one person because something happened. Product and growth teams can design and launch both without engineering, in tools like Courier, Customer.io, Braze, Iterable, Klaviyo, and OneSignal. All of them need an engineer once, to install an SDK and connect a data source. After that, building the flow, writing the content, testing variants, and scheduling the send all happen in a visual editor.

The short version. Most companies run two systems: a marketing tool for campaigns, and something else for product notifications. That's two suppression lists, two preference centers, and two answers when a customer asks why they got four emails today.

Courier is one platform for both, and the only tool here where the same campaign can be built by a person in a visual editor, by an engineer as code, or by an AI agent through the API.

• Pricing: $0.005 per send, the same on every channel, first 10,000 each month free, no contract.
• The alternatives: five of eight can't create a campaign from an API at all, three won't publish a price, four require an annual contract.
• When to pick something else: if all you send is marketing email, Customer.io or Klaviyo.

Who these tools were built for

This category was designed around one buyer: a marketing team clicking in a UI, fed by a data team, on a contract procurement signed. Most of it was built between 2009 and 2014, and none of it has been rearchitected since.

Creatable via API means an endpoint that builds the campaign, not one that triggers a campaign a person already assembled. It's also the AI agent test, since an agent can't drag nodes around a canvas. The partials are narrow: Airship creates Automations but not Journeys, Klaviyo can create a flow but never update it, MoEngage covers email only.

None of that makes them bad software. It makes them software shaped around someone else's org chart, and you inherit three things because of it.

A sales cycle instead of a price. Three of the eight don't publish a price at all, and four require an annual contract with no self-serve tier. The models are per profile, per MAU, per subscriber, or per seat, all from a time when the list was the product, so your bill grows with your database rather than with your product.

A dashboard instead of an API. Five of the eight have no endpoint that creates a campaign. Braze needs a Canvas built in the dashboard first, Iterable's workflow endpoint only triggers, and Intercom's own documentation puts Series and Campaigns outside the API. Your campaigns can't be diffed, code-reviewed, or promoted from staging to production.

AI as a feature instead of a foundation. Subject-line optimizers and send-time tuning sit on top of a fixed pipeline. That's a different thing from running a model as a step inside the flow, and a very different thing from letting an agent build the flow at all.

Courier is the only row that answers all three. The price is published and there's no contract to find out what it is. The API creates campaigns rather than only firing ones a person already built, so they version, review, and promote like the rest of your code. And AI sits inside the flow instead of on top of it: a model can act as a step in the journey, and an agent can build the journey itself.

That's the difference between a tool your growth team logs into and one they own.

What "without engineering help" actually means

Four things still require someone technical. All four are one-time.

The install. Someone adds the SDK or wires up the API and starts identifying users. An afternoon, and it never comes back.

The data connection. Personalization only reaches as far as your data. To branch on plan tier, order value, or last session, those attributes have to flow in from your app, your CDP, or your warehouse. A tool can't segment on something it's never been told.

Deliverability setup. Domain authentication, SPF, DKIM, and DMARC records, plus warming a new sending domain. Gmail and Yahoo enforce this, so it isn't optional.

The CDP fit. Confirm your CDP or warehouse connects cleanly before you sign anything. This is where no-code quietly turns into a six-week integration.

Get those four done once and the growth team owns everything after them. Test that during the trial rather than the demo: connect a real data source and ship one real campaign before anyone signs anything. Every tool here looks self-serve in a demo, because demos start with the data already connected.

Start with what you send

Those four costs are the same everywhere. What differs is what happens afterward, and one thing decides it: how tightly your messages are tied to product state. A newsletter is tied to nothing. An approval request is tied to an event, a payload, and a permission model. The tighter the coupling, the fewer tools survive.

If your work sits in the first two rows, this is a solved problem and you should pick on content tooling and price. Klaviyo, Customer.io, and OneSignal are all genuinely good at it.

Once product events are involved, a UI-only builder stops being a preference and becomes a standing tax. Your engineer emits the event once, which is fine. But every change to the flow after that lives in a dashboard, where it can't be reviewed, promoted between environments, or handed to anyone who isn't clicking.

Below that, the split becomes structural. The marketing suites aren't built for product messages, so you buy a second system, and from then on every preference change, every suppression rule, and every "stop emailing this account" request has to be made twice and stay in sync.

The tools

Courier

Courier runs growth marketing campaigns and product notifications from one system, across email, SMS, push, in-app, Slack, and Microsoft Teams, so there's one set of preferences and one suppression list rather than two of each. A growth team builds journeys and content in the visual editor, an engineer manages the same objects as code, and an agent does either through the MCP server, because all three act on the same objects. An engineer is needed for the initial install and for connecting a data source beyond what your app already sends.

Customer.io

The most mature visual workflow builder aimed at growth teams, strongest in email with solid push and SMS. Segments, drip campaigns, and branching logic are genuinely self-serve once data is flowing. Billing is per profile, so cost tracks your audience rather than your send volume, which bites when you have a large dormant list. No free plan, though there's a startup program that's free for a year if you've raised under $10 million. Engineering owns the initial data pipeline, and transactional or in-app product messages aren't what it's built for.

Braze

The enterprise standard for large-scale lifecycle marketing, with deep segmentation, orchestration, and reporting. Canvas, its journey builder, is capable and entirely UI-driven. It needs an engineer substantially more than the pitch suggests: Braze assumes a data team, and implementations are typically measured in months. Annual contracts, no meaningful self-serve tier.

Fin (formerly Intercom)

Long the default for support-led B2B SaaS teams doing onboarding messages and in-app chat. That isn't the company anymore. It rebranded to Fin around its AI support agent, and Salesforce signed a definitive agreement in June 2026 to acquire it for roughly $3.6 billion, with the agent technology going into Agentforce.

Use it for support, not for product notifications. Alerts, approvals, and digests are exactly what its roadmap is moving away from, and pricing is per seat plus usage, so the bill grows with headcount rather than with sending. Anything you build here is riding a Salesforce-owned roadmap pointed at support automation.

Iterable

Enterprise lifecycle marketing with strong cross-channel orchestration and a good template editor. Sits between Braze and Customer.io on both capability and implementation cost. Engineering owns the data integration plus ongoing catalog and data-feed maintenance for deeper personalization.

Klaviyo

Purpose-built for ecommerce, with native Shopify integration and prebuilt flows for abandoned cart, browse abandonment, and post-purchase. If you sell online, the out-of-the-box flows cover most of day one and you'll barely need an engineer. Considerably more if you're not on Shopify, and it's a poor fit for anything that isn't ecommerce.

OneSignal

Push first, with email and SMS added on. A generous free tier makes it the default for early-stage teams who need push working this week. The campaign builder is straightforward rather than deep, and branching and segmentation are thinner than the marketing suites. Engineering handles the mobile SDK install and push certificates, which are fiddly on iOS.

Airship

Enterprise mobile messaging with strong push infrastructure, rich in-app experiences, and mature audience tooling. A serious option for consumer apps at scale, with mobile SDK work up front and enterprise contracts throughout.

MoEngage

Mobile-first customer engagement with good analytics and campaign tooling, widely adopted in APAC and by consumer app teams. Comparable in scope to Braze at a lower price point. Engineering owns the SDK and event schema, plus meaningful implementation support.

Appcues and Pendo do a different job

Both turn up on lists like this one. They're product-adoption tools for in-app guides, tours, and checklists, and they're good at that. Neither runs email, SMS, or push campaigns. If you need to reach someone who isn't currently in your app, they aren't the answer.

Everything in the Courier UI is on the API

The Courier dashboard is a client of the public API. There's no private backend it talks to that you don't get. Anything you build by clicking, you can build by calling, and both produce the same object.

That covers the whole surface: journeys and their versions, journey templates and their per-locale content, notification templates and individual elements, brands, routing configurations, preference topics, audiences, lists, tenants, user profiles, push tokens, translations, channel provider configuration, and the audit log.

The A/B test a growth manager sets up by dragging variants onto a send node is this same object, readable and writable over the API:

{
  "type": "send",
  "message": {},
  "experiment": {
    "bucketingKey": "user.id",
    "variants": [
      { "id": "control", "name": "Control", "weight": 1, "templateId": "welcome-a" },
      { "id": "shorter", "name": "Shorter copy", "weight": 1, "templateId": "welcome-b" }
    ]
  }
}

Campaigns become reviewable. Journeys are versioned objects you can diff, promote from staging to production, and roll back. A UI-only builder gives you a change log at best, and a colleague clicking around production at worst.

Nobody is the bottleneck. A marketer edits a journey in the canvas. An engineer manages the same journey in a deploy pipeline. Neither waits on the other, and neither has to work in a surface they dislike.

Agents can build. An agent can't operate a canvas, it can call an API. Parity is what turns "describe the campaign, have your agent scaffold it, then open it in the editor" into a real workflow instead of a demo.

What the growth team gets

You design the message in Design Studio, where every channel sits on one canvas with drag-and-drop blocks and your brand styling applied automatically. Then you wire the flow in Journeys by dropping nodes onto edges: send, branch, delay, throttle, batch, or fetch data from an outside service mid-run.

One of those is an AI node that runs an LLM prompt inside the journey, so a model can score a user's churn risk or classify what they wrote, and the next branch acts on the answer. And of the four ways to start a journey, the Audience trigger needs no engineering at all: pick an audience, and it fires when someone enters.

Translation stops being a project. AI translates a journey template into every locale you need, so one journey serves every market instead of one per language, and nobody is shipping strings to an agency and waiting a week for them to come back.

Testing doesn't need a statistician. Put an experiment on any send node with up to ten variants, each with its own template and weight. A bucketing key like user.id keeps a person on the same variant across sends so results stay clean, metrics break down per variant, and promoting one is a deliberate act rather than something that happens to your campaign overnight.

Debugging doesn't need a ticket. Step through a single run against real production data and see what happened at every node. When a campaign misfires, the person who built it can answer "why did this user get that?" without filing anything.

Underneath, preferences and per-topic opt-outs are built in and ungated, one API call reaches any channel so you're not integrating SendGrid then Twilio then Firebase as you grow, and the enterprise pieces are there when you need them: multi-tenancy, SSO, audit trail, EU data residency, and Courier Create if you want your own customers building notifications inside your product.

It costs $0.005 per send, published, the same on every channel. No per-seat charge, so adding a marketer costs nothing. No per-profile charge, so a dormant contact never reaches the bill at all.

What happens when a send fails

A marketing tool can drop an email and nobody notices for a week. A password reset is different, and that gap is the line between a campaign builder and infrastructure you can put product messages on.

Courier retries failed sends automatically with exponential backoff, so transient provider problems like a rate limit or a short outage work themselves out instead of becoming a support ticket. If the primary provider on a channel is unavailable, the next configured provider takes the send. If the whole channel fails, because the user has no email address on file, the message moves to the next channel in priority order. Message Logs show every attempt and the final status, so "did this actually go out" has an answer that isn't a guess.

On the way in, any POST accepts an Idempotency-Key header. Courier caches the first response and replays it for 24 hours, so a retry on your side sends once rather than twice.

The Send API itself isn't rate limited, bounded instead by a 6 MB payload cap and whatever workspace send limits you set. Management endpoints are, at 20 requests a minute on Lists and Events and 200 on Brands, returning 429 when you exceed them.

Get your data in from wherever it lives

The CDP-fit question that stalls no-code projects comes down to one thing: can this tool see your data without months of pipeline work? Courier takes it from four directions, and you don't have to re-model anything to use them.

Straight from your app. Events from your own code through the SDK or API, with no CDP in the middle. For most teams this is the entire setup.

From your CDP. Twilio Segment is a native trigger: pick a source event, and Track, Identify, and Group all work. RudderStack, mParticle, and any other CDP that can fire a webhook connect the same way, with payload fields becoming journey variables.

From your warehouse, by reverse ETL. Point Hightouch or Census at an inbound webhook and a Snowflake, Databricks, or BigQuery table becomes a campaign trigger. The segment your analyst already defined in SQL starts the journey directly, instead of being rebuilt by hand in a marketing tool and drifting out of sync.

Mid-journey, when you don't have it yet. The Fetch Data node calls an external service during a run and makes the response available to every node downstream, so an attribute never has to be pre-loaded anywhere to be used.

Anything that can POST JSON with a userId starts a journey, down to a cron job in your own stack:

{
  "userId": "user_8fc2",
  "plan": "growth",
  "trial_ends_at": "2026-09-01",
  "seats_used": 14
}

Inbound webhooks are self-serve on every workspace. No enterprise plan, no support ticket, no feature flag. In most tools this tier of integration starts with a sales call.

Get the setup done with an AI agent

The one-time work, installing an SDK and wiring a data connection, is scoped, well-documented, and exactly what a coding agent is good at. You don't have to be technical to get it done. What the agent needs is the right context.

Install Courier Skills into Claude Code, Cursor, Codex, or any of the other supported harnesses:

npx skills add trycourier/courier-skills

The skills point the agent at the right Courier APIs and patterns so it builds the correct thing on the first attempt instead of guessing from a stale tutorial. The MCP server is the other half: skills teach an agent how to build, MCP lets it act on your workspace directly, creating journeys, managing templates, and sending.

In practice: describe the campaign in plain language, let the agent scaffold the journey and the data connection, then open it in the visual editor and take it from there. The agent handles the plumbing and you keep the design. It still needs someone with repo access and API keys to deploy its work, so it compresses the setup from a sprint to an afternoon rather than removing the engineer.

Frequently asked questions

Can a marketing team launch notification campaigns without a developer?

Yes, after a one-time setup. A developer installs the SDK, connects your data source, and authenticates your sending domain. From then on the marketing team builds flows, writes and tests content, runs experiments, and schedules sends in a visual editor with no code and no deploy.

What still requires engineering when using a no-code notification tool?

Four things, all one-time: installing the SDK or API client so the tool can identify users, connecting your CDP or warehouse so campaigns can personalize on real attributes, authenticating your sending domain with SPF, DKIM, and DMARC records, and confirming your data sources integrate cleanly before you commit.

Do I need a CDP like Segment to run notification campaigns?

No. A CDP makes it easier by giving you one place to manage identity and events, but it isn't required. You can send events directly from your application, use an inbound webhook from any source that can POST JSON, or pull attributes mid-campaign from an external API. The requirement is a way to identify users and know what they did, not a specific vendor.

Can I connect a data warehouse like Snowflake or Databricks to a notification tool?

Yes, through reverse ETL. Tools like Hightouch and Census sync warehouse tables to downstream destinations. With Courier, a reverse ETL job posts to an inbound webhook and the payload fields become variables in the journey, so a segment defined in SQL can start a campaign directly.

What's the difference between marketing automation and notification infrastructure?

Marketing automation sends campaigns to audiences on a schedule or trigger, optimizing for engagement. Notification infrastructure delivers product messages to individuals in response to events, optimizing for reliability and preference handling. Most companies need both, and running them in separate systems means two suppression lists and two sets of preferences, which is how a customer ends up unsubscribing from everything.

Can an AI agent build a notification campaign for me?

Yes. Installing Courier Skills with npx skills add trycourier/courier-skills gives a coding agent the right API patterns, and the MCP server lets it create journeys and templates in your workspace directly. This works because everything in the Courier UI is available through the API, so an agent can build the same campaign a person would, and you can open its work in the visual editor afterward. Most tools in this category can't do this, because their campaigns exist only in a dashboard.

Which notification tool is best for a growth team working with AI?

Courier. Everything in its UI is available through the API, so an AI agent can build and edit a campaign rather than only trigger one a person already assembled, and a model can run as a step inside a journey to score or classify a user before the next branch acts on it. Pricing is $0.005 per send with a free tier, so you can prove that out before committing to anything. If you only send marketing email and have no product notifications to worry about, Customer.io and Klaviyo remain strong choices.

How do I A/B test a notification campaign without engineering support?

Add an experiment to a send step in the visual editor, give each variant its own template, and set relative weights to split traffic. A bucketing key keeps each person on the same variant across sends so results aren't contaminated. Metrics break down per variant, and you decide when to promote one.

Getting started

Courier is free for the first 10,000 sends a month, which is enough to run real campaigns before you pay anything. Start with the Journeys overview to see how the visual builder works, or hand Courier Skills to your agent and have the setup done this afternoon.