*Last updated: May 2026*

## What "creating notifications with AI" means

![Courier Journey Claude Code Skill header](//images.ctfassets.net/z7iqk1q8njt4/7mt1NK6V1IngYbDqEBA1vh/14b2695efa11df6df2a8d72930c2eb21/courier-journey-claude-code-skill.png?w=600)

Creating a notification with AI means describing what you want to send, to whom, and on which channels, then letting an AI agent or assistant handle the rest: building the template, picking the provider, routing across channels, respecting preferences, and dispatching the message. The agent reads Courier's API surface through the MCP server, generates the right config, and calls the right endpoints. You move from "code an integration" to "describe the outcome."

That shift covers more than just message copy. The agent can:

- Create a [reusable template](https://www.courier.com/docs/platform/content/design-studio/manage-templates-api) that renders to [email](https://www.courier.com/solutions/email-channel), [SMS](https://www.courier.com/solutions/mobile-channel), push, [Slack](https://www.courier.com/solutions/ms-teams-slack-channel), and [in-app inbox](https://www.courier.com/platform/inbox) from one definition.
- Read your connected channel providers (Gmail, SendGrid, Twilio, FCM, Slack) and route through the ones you've set up.
- Build a [customer journey](https://www.courier.com/solutions/customer-journeys) (multi-step flow with delays, branches, and conditions).
- Send a message, fetch the delivery log, and react to bounces.
- Apply user [preferences and quiet hours](https://www.courier.com/platform/preferences-management) without extra code.

Courier exposes this whole surface to AI tools through the [Courier MCP server](https://www.courier.com/docs/tools/mcp) at *mcp.courier.com* and the [Courier CLI](https://www.courier.com/docs/tools/cli) (*@trycourier/cli*). Both authenticate with the same API key from your Courier workspace: the MCP server takes it as an *api\_key* header in your AI tool's MCP config, the CLI reads it from *COURIER\_API\_KEY*. Same surface, two transports.

## A 60-second look at what this looks like

The simplest way to feel the difference: connect a provider once in the [Courier dashboard](https://app.courier.com), point your AI tool at the Courier MCP server, then prompt.

> "Create a welcome email template that thanks the user by first name. Send a test to alex@example.com."

The agent calls two MCP tools in sequence: *create\_notification* to build the template in [Elemental](https://www.courier.com/docs/platform/content/elemental/elemental-overview), Courier's cross-channel JSON format, and *send\_message* to dispatch the test. The send call returns a *requestId* you can use to check the log. The whole flow, including dashboard provider setup, takes about three minutes.

If you'd rather drive Courier from the terminal, the [Courier CLI](https://www.courier.com/docs/tools/cli) is the same surface. With *COURIER\_API\_KEY* exported in your shell, *courier notifications create* builds the template and *courier send message* dispatches it. The CLI accepts the message body as either flat dotted flags (*--message.to.email*, *--message.content.title*, *--message.content.body*) or piped JSON. Or hit Courier's REST API directly from your application code. The primitives are the same regardless of surface.

## How Courier fits between your app and the user

![Pushbullet Alternative: How to Build Cross-Device Product Messages](//images.ctfassets.net/z7iqk1q8njt4/5HbZnyJj0bmAeiSSyGBWCO/655cc5460478afec0ce787f50f4ad7d2/Frame_163979__3_.png?w=600)

The pattern Courier formalizes is *Your App → Courier → Providers → User*. You give Courier a recipient and a message; Courier handles routing, preferences, retries, and logging automatically.

When you (or your agent) call *POST /send*, Courier resolves the recipient from a stored profile if you passed a *user\_id*, picks the channels the user has opted into, renders the template for each one, and dispatches through your connected providers in the order your routing config defines (priority, fallback, or engagement-based). Every event (rendered, sent, delivered, opened, clicked, bounced) lands in the message log filterable by user, template, journey, or run. The [agent quickstart](https://www.courier.com/docs/tools/agent-quickstart) recommends sending to *user\_id* rather than inline email so the same profile is reused for preferences, idempotency, and cross-channel routing.

This is the model behind every example in the rest of the guide. The four shifts below are all about who is responsible for setting up and operating this pipeline. The answer used to be "a developer for a week." Now it's "an AI agent for a few minutes." For a longer take on what changes when AI handles the work, see [Turn customer context into personalized messaging with AI](https://www.courier.com/blog/turn-customer-context-into-personalized-messaging-with-ai) and [Customer Engagement Platforms Are Splintered. Message Orchestration Is the Fix](https://www.courier.com/blog/customer-engagement-message-orchestration).

## The four shifts

### 1. Install through MCP and CLI

Two surfaces matter. The [MCP server](https://www.courier.com/docs/tools/mcp) is the AI-tool integration point: a remote endpoint at *mcp.courier.com* that exposes Courier's API as 109 typed tools across send, messages, profiles, lists, audiences, notifications, brands, journeys, providers, tenants, automations, bulk operations, device tokens, and audit events. Any MCP-capable client (Claude Code, Cursor, Windsurf, Claude Desktop, VS Code, plus the OpenAI Responses API) connects by adding the server URL to its MCP config and passing your Courier API key as an *api\_key* header. There is no separate OAuth flow; the same key you use against the REST API is the key the MCP server reads.

The [CLI](https://www.courier.com/docs/tools/cli) (*@trycourier/cli*) covers the same surface from the terminal. It reads *COURIER\_API\_KEY* from your environment and ships with no other runtime dependencies. It's the right tool for CI/CD, scheduled jobs, and operational tooling where you want a deterministic action without an LLM in the loop.

Chapter 2 walks through both installs in detail.

### 2. Design and send by prompt

![claude_code_template_creation](//images.ctfassets.net/z7iqk1q8njt4/2lzCzGKcFH8c01G8I5YsBJ/37e20b10f75dd37527f82f3e4bf2aa49/claude_code_template_creation.png?w=600)

Courier represents a message in [Elemental](https://www.courier.com/docs/platform/content/elemental/elemental-overview), a JSON-based templating format that lets you define a notification structure once and customize it per channel, locale, or user context. A single Elemental document renders to email, SMS, push, Slack, Microsoft Teams, WhatsApp, and the in-app inbox.

When an AI agent generates a message, it generates Elemental. That means one prompt produces one template that works everywhere you've connected a channel. You skip the "write the email, write the SMS, write the push, keep them in sync" loop.

Elemental supports text, images, action buttons, dynamic data via templating, conditional rendering with *if:* expressions, lists, and per-channel overrides. Chapter 3 covers how to build templates by prompt, by CLI, by API, or in the Design Studio, and how to send them through any of those surfaces.

### 3. Journeys built by AI

![generic_journeys](//images.ctfassets.net/z7iqk1q8njt4/SC7dGKZHtjGrN7fJP9KcW/9a100cdd1ee0b666c38ee72064c4f212/generic_journeys.png?w=600)

A [journey](https://www.courier.com/docs/platform/journeys/journeys-overview) is a directed graph of nodes that executes when triggered. The node types are:

| Node | Purpose |
|------|---------|
| Trigger | The entry point. API-invoke or event-based. Optional schema declares the data the journey expects. |
| Send | Deliver a message through one or more channels via a journey-scoped template. |
| Delay | Pause for a duration or until a specific time. |
| Branch | Split into paths based on conditions. Requires a *default* path so no run falls off the edge. |
| Fetch | Pull data from your API or an external service mid-run. |
| AI | Call an LLM with a templated prompt. Requires a *model*, *user\_prompt*, and *output\_schema*. |
| Throttle | Cap concurrent runs at a global, user, or dynamic-key scope. |
| Exit | End the path. |

The [Journeys API](https://www.courier.com/docs/platform/journeys/building-journeys-via-api) accepts a journey as a JSON document with a *nodes* array. When you say "build a trial-ending journey that emails the user at day 11, waits 2 days, branches on whether they upgraded, sends a push if not, then exits," the agent creates the journey shell, creates and publishes the journey-scoped templates the sends will reference, replaces the journey with the wired body, and publishes it. Send nodes cannot be included in the initial create call; the templates have to exist and be published first. Chapter 4 covers the full flow and the guardrails to set before letting AI publish to production.

### 4. Agents that send messages

The fourth shift is the agent itself becoming the sender. A customer-support agent that closes the loop with an email receipt. A workflow agent that pages on-call when a deploy fails. An in-product AI feature that pushes a notification when a long-running task finishes.

The Courier MCP server gives any agent a complete messaging surface in one integration: identity (profiles by *user\_id* and *tenant\_id*), [preferences](https://www.courier.com/docs/platform/sending/sending-overview) (channel opt-ins, frequency caps), [rate limiting](https://www.courier.com/docs/platform/sending/send-limits), and audit logs. The agent doesn't need to know how Twilio's webhook signatures work. It calls *send\_message*, Courier handles the rest.

Chapter 5 covers agent-side patterns: how to scope what an agent can send, how to log what it did and why, dry-run mode, and approval gates for high-stakes sends.

## Skills: the prompt-side counterpart

Alongside the MCP server, Courier publishes [skills](https://www.courier.com/docs/tools/courier-skills): agent skill packs that teach AI coding assistants Courier notification best practices. A skill is a *SKILL.md* markdown file (plus task-specific resource files) that lives in your AI tool's skills directory. The tool reads *SKILL.md* when a relevant prompt comes in and follows the routing inside.

The whole bundle ships in a single repository, [*trycourier/courier-skills*](https://github.com/trycourier/courier-skills), which you clone into your harness's skills directory. For Claude Code that path is *~/.claude/skills/courier-skills*; for Cursor it's *~/.cursor/skills/courier-skills* globally or *.cursor/skills/courier-skills* per project; Windsurf, Cline, and other agents use their own equivalents. There is no one-shot plugin install command; clone the repo, point your tool at it, and the skills become available next session.

Today's skills cover 7 channels (email, SMS, push, in-app inbox, Slack, Microsoft Teams, WhatsApp), 5 transactional notification types (authentication, orders, billing, appointments, account), 6 growth flows (onboarding, adoption, engagement, re-engagement, referral, campaigns), and 10 cross-cutting guides like multi-channel routing, preferences, compliance, reliability, batching, and throttling.

The MCP server is the API surface (what the agent can do). Skills are the playbook (how to do it well). You install both. Chapter 2 covers the install.

## AI alerts vs. AI notifications: same thing?

Mostly yes. "AI alerts" usually refers to the source: an alert that an AI system produced, like a [Datadog](https://www.datadoghq.com/) AI ops alert, an anomaly score from a fraud model, or an LLM-flagged security event. "AI notifications" refers to the delivery: any product message where AI helped design, route, or send it. The two terms describe different parts of the same pipeline.

In practice, you almost always need both. An ML model that flags suspicious activity is useless if you can't get the alert to the right person on the right channel at the right time. An AI agent that drafts a refund email is useless if it can't actually send it to the customer. The interesting work, and where most teams get stuck, is in the delivery layer: routing the alert through the right channel, respecting the user's preferences, retrying on a bounce, deduplicating across the three providers you're using.

If you're routing AI-generated content to people through email, SMS, push, Slack, or in-app, you're working on AI notifications. If your alerts are AI-produced and you need to dispatch them somewhere, the dispatch problem is an AI notifications problem.

The plumbing is the same either way: cross-channel templates that render once and dispatch many ways, user preferences and tenant isolation, idempotency and retries, audit logs that show what fired and why. Building that plumbing by hand for a new product was a multi-week project. With Courier's MCP server and CLI, your AI tool stands it up in an hour, and you spend your time on the AI part instead.

### Where AI alerts come from

![dual platform messages](//images.ctfassets.net/z7iqk1q8njt4/1rDgpfQ6ZuNL94H2IPHm7G/3cb2c9c0d4f37af46d4eea73d55f4a4c/Work.png?w=600)

[Alert notifications](https://www.courier.com/solutions/alert-notifications) come from a handful of recurring sources:

- **Observability tools** (Datadog, Sentry, Grafana) firing AI-augmented anomaly detection.
- **Security tools** (CrowdStrike, Snyk, Wiz) flagging events with LLM-assisted triage.
- **Fraud and risk models** scoring transactions or sessions.
- **Customer-success signals** generated by LLMs reading support tickets or product telemetry.
- **In-product AI features** finishing a long-running task that the user is waiting on.

Each one needs a delivery layer to reach a person. That layer is what this guide covers.

## Who this guide is for

If you're shipping a product that needs to message users and you'd rather have an AI do the integration work, this is for you. Concretely:

- **Developers** integrating notifications into a new product or replacing legacy notification code.
- **AI engineers** building agents that need to send messages as part of their loop.
- **Product managers** who want to prototype a messaging flow without filing a ticket.
- **Indie builders and founders** shipping AI products who don't want to spend a sprint on email infrastructure.

Familiarity with REST APIs and JSON helps but isn't required. If you can prompt an AI tool, you can follow along.

## What you'll build

By the end of this guide you'll have the Courier MCP server and CLI installed in your AI tool of choice with at least one channel provider connected (Chapter 2). You'll have generated a working multi-channel notification template from a prompt and sent it as a test message (Chapter 3). You'll have built a customer journey with branching logic from a description rather than a drag-and-drop builder (Chapter 4). You'll have wired an autonomous agent loop that can send notifications, respect user preferences, and stay within rate limits (Chapter 5). And you'll have a clear picture of where AI notifications fit in real-world product, ops, and support use cases (Chapter 6).

Every step is shown with the actual CLI commands, API calls, or MCP tool calls that produce the result. You should be able to copy the prompts and have your AI tool execute them against your own Courier account. If you want a faster end-to-end walkthrough, the [AI onboarding guide](https://www.courier.com/docs/tools/ai-onboarding) covers the same setup in tutorial form, and Courier publishes a machine-readable docs index at [*courier.com/docs/llms.txt*](https://www.courier.com/docs/llms.txt) so agents can discover capabilities on their own. For the broader narrative on how this shift is changing the way teams ship messaging, see [Anyone on your team can ship a Courier journey from a prompt](https://www.courier.com/blog/create-journey-from-ai) and [Build with AI: let your agent handle notifications end to end](https://www.courier.com/blog/build-with-ai-agent-notification-toolkit).

[LaunchDarkly](https://www.courier.com/use-cases/launchdarkly) uses Courier for the multi-channel notifications behind their Feature Workflows product, including Slack-based release approvals. The engineering team picked Courier specifically for cross-channel routing, SOC 2 compliance, and the ability to fit the existing Go SDK and provider stack.

---

Ready to put this into production? [See pricing](https://www.courier.com/pricing) or [talk to our solutions team](https://www.courier.com/request-demo).

## FAQs

### What does "create notifications with AI" actually mean in practice?

It means an AI agent (in Claude Code, Cursor, Windsurf, Claude Desktop, or any other MCP-capable client) reads your Courier account through the MCP server at *mcp.courier.com*, generates the right templates and journey definitions from your description, and calls the right endpoints. You describe the outcome ("send a welcome email when a user signs up, follow up after 3 days if they haven't completed setup"); the agent builds it. You're not writing template JSON or provider configuration code by hand.

### What changes when notifications are built with AI instead of by hand?

The configuration work disappears. Building a notification system used to mean integrating one provider per channel, writing one template per message per channel, and writing application code to glue them together. With AI plus the MCP server, the agent does the configuration, generates the templates from a description, and produces the send code that calls Courier's API. You spend your time on what to send, not how to send it.

### Do I need to rebuild my existing notification system to use AI?

No. Courier sits in front of whatever providers you already use. If you have SendGrid for email and Twilio for SMS, the MCP server can read your existing setup and add new templates or journeys without changing the providers. You can adopt one piece at a time.

### Is this for engineers, product builders, or both?

Both. The MCP server exposes the same surface to a developer prompting Claude Code as it does to a PM prompting Claude Desktop. The output (a template, a journey, a send call) is the same. The difference is who's driving.

### What's the difference between AI alerts and AI notifications?

"AI alerts" usually refers to the AI-generated content (an anomaly detection alert, a fraud signal, an LLM-flagged event). "AI notifications" refers to the delivery layer: how that content reaches a person through email, SMS, push, or chat. You almost always need both. This guide is about the delivery layer.

### What's the difference between the MCP server, the CLI, and skills?

The MCP server is the API surface for AI tools, accessed at *mcp.courier.com*. The CLI (*@trycourier/cli*) is the same surface from the terminal. Skills are file-based guidance packs cloned into your AI tool's skills directory that teach the agent how to use Courier well. All three are free and live alongside each other. Chapter 2 covers installing each.


What creating notifications with AI means: Courier's MCP and CLI, the four shifts behind AI-built messaging, and how AI alerts and notifications relate.

Create Notifications with AI: Builder's Guide | Courier

Creating a notification with AI means describing the outcome and letting an agent build the template, configure providers, route across channels, and dispatch the send. This chapter introduces the Courier model (Your App → Courier → Providers → User), the four shifts (install through MCP and CLI, design and send by prompt, AI-built journeys, agents as senders), and how AI notifications and AI alerts relate.

Introduction: Creating Notifications with AI

*Last updated: May 2026*

## The pieces

Courier's [notification infrastructure](https://www.courier.com/platform/notification-infrastructure) ships two programmatic surfaces for managing it outside the dashboard:

- **The [MCP server](https://www.courier.com/docs/tools/mcp)** at *mcp.courier.com*, for AI tools to read and write your Courier account from inside a prompt.
- **The [CLI](https://www.courier.com/docs/tools/cli)** (*@trycourier/cli*), for terminals, scripts, and CI to do the same operations from the command line.

Both read the same Courier API and authenticate with the same API key from your workspace. The MCP server is a remote HTTP MCP endpoint, so there's nothing to install on your machine for it; you add the URL to your AI tool's MCP config and pass the key as an *api\_key* header. The CLI is an npm package you install once and authenticate by exporting *COURIER\_API\_KEY* in your shell.

Most teams install both. The MCP server is what your AI tool uses day to day. The CLI is what you reach for in CI/CD, in setup scripts, or when you want a deterministic action without going through an LLM. There's a real debate about when each is the right tool, covered in [Your AI agent already knows how to use a terminal. Why CLIs beat MCP servers](https://www.courier.com/blog/your-ai-agent-already-knows-how-to-use-a-terminal-why-cli-beat-mcp-servers) and [Terminal-First Development vs. IDE: Building Notification Infrastructure](https://www.courier.com/blog/terminal-first-development-vs-ide-building-notification-infrastructure-with).

Before either, you need:

1. **A Courier account.** Free tier is fine. Sign up at [courier.com](https://www.courier.com/). See current [plan limits](https://www.courier.com/pricing) for what fits your volume.
2. **An API key.** Generated from Settings → API Keys in the Courier dashboard. The same key works for the CLI, the MCP server, the REST API, and every Courier SDK. Note that Courier exposes a Test and a Production environment, each with its own key; use the Test key while you're wiring things up and switch to Production when you're ready for real traffic.

Both install in a couple of minutes. Start with whichever path matches what you'll do first.

## Installing the Courier MCP server

The MCP server is a remote HTTP endpoint at *`https://mcp.courier.com`*. Every MCP-capable client connects the same way: add the URL, pass your Courier API key as an *api\_key* header, and the 109 Courier tools become available the next time your tool refreshes its tool list. There is no OAuth flow; the same API key you'd use against the REST API is the one the MCP server reads.

The install snippet your client needs:

- **Claude Code** uses one command: *claude mcp add --transport http courier `https://mcp.courier.com` --header api\_key:YOUR\_COURIER\_API\_KEY*. That writes the entry into your Claude Code MCP config and the tools show up in your next prompt.
- **Cursor** edits its config under **Cursor Settings → Tools & Integrations → MCP Tools → New MCP Server**. The entry is a small JSON block with the server *url* set to *`https://mcp.courier.com`* and a *headers* object containing *api\_key*.
- **Windsurf** uses **Windsurf Settings → Manage MCP Servers → View Raw Config**. Same shape as Cursor (server URL plus an *api\_key* header), under the *mcpServers* key.
- **Claude Desktop** doesn't speak remote HTTP MCP natively, so it goes through a stdio shim: in **Claude → Settings → Developer → Edit Config**, add a server entry that runs *npx -y mcp-remote `https://mcp.courier.com` --header "api\_key: YOUR\_COURIER\_API\_KEY"*.
- **VS Code** uses a workspace file at *.vscode/mcp.json* with the server URL, *type: "http"*, and the *api\_key* header.
- **OpenAI's Responses API** accepts the MCP server as a tool configuration with *type: "mcp"*, the server URL, and the API key in headers.

Whichever client you're on, the [MCP docs page](https://www.courier.com/docs/tools/mcp) has the exact config block to copy in. For the underlying implementation see [The Courier MCP Server Is Open Source. Here's How It Actually Works](https://www.courier.com/blog/courier-mcp-server-open-source-how-it-works).

A scope note worth knowing up front: connecting channel providers (Gmail OAuth, Twilio API key, Slack bot token, and so on) happens in the [Courier dashboard](https://app.courier.com), not through MCP. Once a provider is connected, every send the agent dispatches runs through it. Provider management surfaces in the API mostly handle reading configuration and routing rules, not first-time provider OAuth.

## Installing the Courier CLI

The CLI is published as [*@trycourier/cli*](https://github.com/trycourier/courier-cli) on npm. A global install (*npm install -g @trycourier/cli*) is the usual choice; *npx @trycourier/cli* works for ad-hoc invocations without a global install.

The CLI reads *COURIER\_API\_KEY* from your environment. Export it in your shell profile and every subcommand picks it up automatically. There is no separate *courier auth* or *courier login* command; the env var is the auth model. The *--api-key* flag overrides it for one-off calls, which is the right pattern when you bounce between Test and Production keys.

The CLI exposes Courier's REST surface as resource groups: *send*, *messages*, *notifications*, *profiles*, *lists*, *bulk*, *tenants*, *user-tenants*, *automations*, *preferences*, plus *journeys*, *providers*, *brands*, *routing-strategies*, *translations*, and *audiences*. The two you'll reach for first are *courier send message* (to dispatch a message) and *courier messages list* (to inspect deliveries). The send command takes the message body as flat dotted flags: *--message.to.email*, *--message.content.title*, *--message.content.body*, *--message.template*, *--message.data*, and so on, which is the same shape the REST API accepts under its *message* key. For CI use, set *COURIER\_API\_KEY* as a secret and shell out to *courier* directly; the exit code is non-zero on failure, and *--format json* (or *jsonl*, *yaml*, *raw*) makes the output pipeable. Full reference at [the CLI docs](https://www.courier.com/docs/tools/cli).

As of CLI 3.4.2, the *courier journeys* resource ships *list* and *invoke* only. The create, replace, publish, and journey-scoped template operations don't have CLI commands yet; for those, use a Courier SDK or hit the REST endpoints directly. The */courier-journeys-create* skill (covered next) falls back to SDKs automatically when it needs operations the CLI doesn't ship.

## Installing Courier skills

A [skill](https://www.courier.com/docs/tools/courier-skills) is a packaged set of instructions your AI tool reads when a relevant prompt comes in. The skill format is a *SKILL.md* markdown file with a small YAML header (name, description, trigger phrases) plus task-specific resource files the skill references. The tool loads the skill when the user's prompt matches and follows the routing inside.

Courier publishes the whole skill bundle in one repository, [*trycourier/courier-skills*](https://github.com/trycourier), which you clone into your harness's skills directory:

- **Claude Code** discovers skills under *~/.claude/skills/*. Clone into *~/.claude/skills/courier-skills*.
- **Cursor (global)** uses *~/.cursor/skills/*. Clone into *~/.cursor/skills/courier-skills*.
- **Cursor (project-scoped)** reads *.cursor/skills/* next to the project. Clone into *.cursor/skills/courier-skills* inside the repo.
- **Windsurf, Cline, and other agents** follow the same pattern: clone into whatever skills directory the tool supports.

There is no one-shot plugin install command (*claude plugins add courier* is not a real command). Clone the repo, point your tool at it, and the skills become available next session.

The */courier-journeys-create* skill, the */courier-template-create* skill, and the *courier-writing-guide* come bundled, alongside reference files for the seven channels (email, SMS, push, in-app inbox, Slack, Microsoft Teams, WhatsApp), five transactional notification types, six growth flows, and ten cross-cutting topics like multi-channel routing, preferences, compliance, and reliability. Skills are scoped: they only activate when the prompt matches, so you can install the whole bundle and the right skill loads per prompt. See [Introducing Courier Skills](https://www.courier.com/blog/introducing-courier-skills-teaching-your-ai-ide-to-build-notifications) for the why-and-how on the skill format. Chapter 5 covers the broader pattern of giving an autonomous agent messaging tools, including the safety guardrails to set up before letting it send without review.

> "The first comment I received from a developer when they first started to use Courier was how easy it was to create a new notification."
>
> **Marc-André, Officevibe** (the team replaced an in-house notification system with Courier so they could focus on product instead of infrastructure)

## Connecting your first channel provider

A channel provider is the actual sender for a channel: Gmail or SendGrid for email, Twilio for SMS, FCM or APNS for push, Slack for chat. Provider setup happens in the [Courier dashboard](https://app.courier.com) under Channels. The first one is the easiest, and Gmail is the easiest first one because the dashboard walks you through OAuth in the browser, stores the credentials, and registers it as an available email provider with no API key to manage. See [the Gmail provider docs](https://www.courier.com/docs/external-integrations/email/gmail) for what gets stored.

For providers that use an API key (SendGrid, Twilio, Postmark, Slack bot tokens, FCM service accounts), paste the credential into the dashboard's provider page and save. Courier stores it server-side; your agent never sees it, and your application code never has to handle it. Once a provider is connected, every send call routes through it automatically based on the notification's routing config.

If you'd rather list providers from the terminal, *courier providers list* returns the configured set, and *courier providers:catalog* lists every provider Courier supports. Provider creation itself, though, lives in the dashboard.

## Verifying the install: your first send

Test the install by sending a real message. Through the agent: "Send a test email to alex@example.com that says 'Courier is connected.'" From the CLI:

```bash
courier send message \
  --message.to.email "alex@example.com" \
  --message.content.title "Courier is connected" \
  --message.content.body "Hello from the CLI."
```

Either way you'll get a *requestId* back and the message arrives in a few seconds. If it doesn't, fetch the log with *courier messages list --recipient alex@example.com* and drill into a specific message with *courier messages retrieve --message-id <id>*. The log includes provider response codes and any channel errors. Chapter 3 covers designing real templates instead of inline content, plus the production patterns (*user\_id* recipients, idempotency keys, webhook handling) the [agent quickstart](https://www.courier.com/docs/tools/agent-quickstart) recommends once you're past the test send.

## FAQs

### What does the MCP install actually do?

It registers a remote HTTP endpoint with your AI tool and tells it to pass your Courier API key as an *api\_key* header on every call. The endpoint exposes Courier's API as a set of typed tools (*send\_message*, *create\_notification*, *invoke\_journey*, and so on). When your agent decides it needs to do something Courier-related, it picks the right tool and calls it. The agent never has to read Courier's REST docs because the tool definitions include parameter schemas and descriptions.

### Do I need an API key to start?

Yes for both. The MCP server reads the API key from the *api\_key* header your client passes; the CLI reads it from *COURIER\_API\_KEY*. Generate the key from the Courier dashboard under Settings → API Keys. Test and Production environments each have their own key.

### Do I need both the MCP server and the CLI?

No, but most teams install both. The MCP server is the AI-tool surface. The CLI is the terminal and CI/CD surface. They share the same underlying API, so anything you do in one is visible in the other (a template created through the agent shows up in *courier notifications list*).

### Can a teammate share my MCP setup?

The MCP server URL is the same for everyone. Each teammate adds the same *mcp.courier.com* URL to their AI tool's config and supplies their own Courier API key. The key determines which workspace they reach; if you're sharing a workspace, you each generate a key from your own user and the server scopes calls accordingly.

### What's the difference between the MCP server and a skill?

The MCP server is the API surface. It exposes tools the agent can call. A skill is a prompt-time instruction that tells the agent how to use those tools for a specific task. The MCP server is required. Skills are optional but make common tasks more reliable.

### Which AI coding tools does Courier work with?

Any tool that supports MCP. Today that includes Claude Code, Cursor, Windsurf, the Claude Desktop app, VS Code, and OpenAI's Responses API. As new MCP-compatible tools ship, Courier works with them automatically since the protocol is standardized. See the [AI onboarding guide](https://www.courier.com/docs/tools/ai-onboarding) for a tool-by-tool walkthrough and a machine-readable docs index at [*courier.com/docs/llms.txt*](https://www.courier.com/docs/llms.txt) that an agent can fetch on its own.

---

Ready to put this into production? [See pricing](https://www.courier.com/pricing) or [talk to our solutions team](https://www.courier.com/request-demo).


Install the Courier MCP server for AI tools and the Courier CLI for the terminal. Connect a provider, send a test message in minutes.

Install Courier MCP Server and CLI: Setup Guide | Courier

Install both Courier surfaces: the MCP server for AI tools (Claude Code, Cursor, Windsurf, ChatGPT, Claude desktop) and the CLI (@trycourier/cli) for terminals and CI/CD. Connect a channel provider, then verify with a test send from either prompt or CLI.

Install the Courier MCP Server and CLI

*Last updated: May 2026*

If you haven't installed the MCP server or CLI yet, start with Chapter 2. This chapter assumes both are ready and at least one channel provider is connected.

## How Courier represents a message across channels

A notification template in Courier isn't tied to one channel. The same template you send as an email also renders as an SMS, a push notification, a Slack message, and an in-app inbox entry, with each channel using the format and constraints that make sense for it. That's the practical advantage of cross-channel notification infrastructure: you describe a message once and Courier handles the rendering for each surface it ends up on.

Courier uses a format called [Elemental](https://www.courier.com/docs/platform/content/elemental/elemental-overview) to describe a message. Elemental is JSON: a structured document of typed elements (text, action buttons, images, dividers, channel overrides, conditional blocks) that the rendering layer translates into channel-appropriate output. A trial-ending message in Elemental is a couple of elements: a text block ("Your trial ends in 3 days.") and an action block with a button labeled "Upgrade your plan" pointing at your billing page. That single document renders as an email with a button, a push notification with a deep link, an SMS with the link inline, a Slack message with a button, and an in-app inbox message with an action. The Courier rendering layer translates each *element* into the right primitive for each channel.

Elements also support an *if:* expression for conditional rendering inside the template, so a hero image can vary per segment or a section can be gated by a data field without splitting the template. The condition reads any path available at render time: trigger data, fetch-merged data, profile fields, or AI output.

You don't have to write Elemental by hand. The MCP server's *create\_notification* tool accepts a description in English and produces the Elemental JSON. When you ask an agent to "build a trial-ending email with an upgrade button," it generates the structure and stores the template in your workspace. [Using Claude Design, Claude Code, and Courier AI to Create a Multichannel Onboarding](https://www.courier.com/blog/claude-design) walks through the full prompt-to-template path with real screenshots, and [How to Use Claude Code on Mobile to Design, Test, and Ship Multichannel Notifications](https://www.courier.com/blog/claude-code-courier-ai-multichannel-notifications-from-phone) covers the same flow from a phone.

## Four surfaces: CLI, API, prompts, Studio

You have four surfaces for building and sending messages. Prompts (via the MCP server) for ideation and one-off messages. The CLI for terminals, scripts, and CI/CD. The REST API for application code calling Courier in production. And the [Design Studio](https://www.courier.com/platform/design-studio) for visual fine-tuning. All four read and write the same underlying template, so a template built one way is editable in any other. Pick the surface that matches the task: prompts win for speed, CLI for repeatability, API for production, Studio for polish. [How Product Teams Build, Test and Ship Multichannel Notifications in Design Studio](https://www.courier.com/blog/how-product-teams-build-multichannel-notifications) covers the design-and-test loop in depth.

> "We were happy to get out of the business of having to design email templates and all of that awful stuff that comes with it."
>
> **Peter, Apartment List** (engineering team adopted Courier as a central platform service across the company)

## Multi-channel from day one

![template_builder](//images.ctfassets.net/z7iqk1q8njt4/6RsSlZbEnu1pjZ5CaoV5Ya/bb3c5d1aea1a4e5af7cea4f805fae7f0/template_builder.png?w=600)

The reason Elemental matters is that one template targets multiple channels. With a single template you can:

- Send an [email](https://www.courier.com/solutions/email-channel) with full HTML rendering, an unsubscribe footer, and inline images.
- Send a 160-character SMS that strips out the visual blocks and keeps the action link.
- Send a [mobile push notification](https://www.courier.com/solutions/mobile-channel) with a title, body, and deep link.
- Post a [Slack or Microsoft Teams message](https://www.courier.com/solutions/ms-teams-slack-channel) with a button or block kit elements.
- Drop a message into the [in-app inbox](https://www.courier.com/platform/inbox) with read state tracking, using Courier's [in-app channel](https://www.courier.com/solutions/in-app-channel) components.

That 160 assumes standard Latin text. One emoji or curly quote switches the message to UCS-2 encoding and drops the budget to 70 characters per segment, which the [SMS preview generator](https://www.courier.com/tools/sms-preview-generator) counts as you type.

The send call takes a recipient, a template ID, and the data values that fill the template. Courier looks up the recipient's preferences, picks the channels they've opted into, and dispatches the message through your connected providers.

Multi-channel doesn't mean "send the same thing five times." A user with both email and push enabled doesn't need to get both for a low-priority message. Courier's [routing](https://www.courier.com/docs/platform/sending/sending-overview) and [preferences management](https://www.courier.com/platform/preferences-management) let you set channel priority and fallback behavior so the user gets the message once, through the right channel. If you omit the *routing* block on the send, Courier uses the template's configured routing; pass *routing.method* and a *channels* array on the send to override per call.

## Brands and templates

Templates have content (text, buttons, dynamic data). Brands have look and feel (logo, fonts, colors, footer). A template references a brand, which means you can rebrand without touching templates.

You can ask the agent to set up your brand:

> "Set up our brand. Logo is at brand.example.com/logo.png, primary color is #4F46E5, footer copy is '© 2026 Example Inc.'"

The agent creates the brand record and links it to your default template settings. Every new template inherits it.

If you operate multiple brands (white-labeling, a parent company with sub-brands), Courier supports a brand per template or a brand per tenant. The agent can configure either, but pick the model up front because changing later means re-linking templates.

## Sending a test message

![claude_code_template_creation](//images.ctfassets.net/z7iqk1q8njt4/2lzCzGKcFH8c01G8I5YsBJ/37e20b10f75dd37527f82f3e4bf2aa49/claude_code_template_creation.png?w=600)

Once you have a template, sending a test is one call. You have three ways to make it.

Through your AI agent, ask it directly: "Send the trial-ending template to alex@example.com with first_name Alex." The agent picks the template ID, fills in the recipient and merge data, and dispatches.

Through the CLI, the same call uses dotted flags:

```bash
courier send message \
  --message.to.email "alex@example.com" \
  --message.template "<TEMPLATE_ID>" \
  --message.data '{"first_name": "Alex"}'
```

Through the REST API, *POST https://api.courier.com/send* with the same body wrapped in a *message* key and your API key as a Bearer token in the *Authorization* header. See [the sending overview](https://www.courier.com/docs/platform/sending/sending-overview) for the full schema.

All three return a *requestId* you can inspect in [the message logs](https://app.courier.com/data/logs/messages) or fetch with *courier messages retrieve --message-id <id>*. A *200* on the send is acceptance, not delivery; check the message log to see the per-channel result.

During early development, stay in the Test environment (its own API key, sandbox-only providers, built-in email so you don't have to wire Gmail or SendGrid before the first send). Switch to the Production key the same code reads when you're ready for real traffic.

## Going to production

Three things change when you move from testing to production messages going to real users:

**Identify users by a stable ID, not by email.** Send to a *user\_id* and Courier looks up the stored profile (email, phone, push tokens, Slack ID) and preferences against that user. Profiles are created with *POST /profiles/{user\_id}* (*courier profiles create --user-id <id> --profile '{"email":"..."}'* from the CLI), and *POST* merges fields while *PUT* replaces them. Sending only by inline contact info works for transactional flows but breaks down when a user updates their email or you want preference center support. See the [agent quickstart](https://www.courier.com/docs/tools/agent-quickstart) for the patterns Courier recommends around profiles and idempotency.

**Use idempotency keys.** Pass an *Idempotency-Key* HTTP header on the send call. If your code retries due to a network blip, Courier deduplicates against the stored response and the user gets the message once. Two notes worth knowing: replaying a key that previously errored returns the stored error unchanged (it does not retry with a corrected payload), and in the Node SDK the *idempotencyKey* request option silently no-ops, so pass the key in *headers* instead.

**Handle delivery errors as events, not exceptions.** A bounced email or a failed push doesn't fail the send call. It shows up in the message log with a status. Subscribe to delivery webhooks (or poll the log) and react to permanent failures by updating the user's preferences or deactivating the channel.

For anything more complex than a single send, you want a journey: a multi-step flow with delays, branches, and conditions. Chapter 4 covers how an AI agent can build one from a description.

## FAQs

### Do I have to write Elemental JSON by hand?

No. The agent generates Elemental for you. You write a description, the agent produces the JSON, and the template gets stored in Courier. You can read and edit the JSON if you want, but most of the time you won't need to.

### How do I preview a message before sending?

Two options. From the Studio, open the template and click Preview, which renders email, SMS, push, and inbox side by side. From the agent, ask for a preview: "Show me how the trial-ending template will render for alex@example.com." The agent calls the preview endpoint and returns the rendered output.

### How do channel fallbacks work?

In the routing config for a notification, you set a channel order. Email first, push second, SMS third. Courier tries the first channel. If the user hasn't opted in or the channel fails permanently, it moves to the next. You can also configure "best of" routing where Courier picks the channel most likely to be read based on past engagement.

### Can I edit an AI-generated template in the Studio later?

Yes. Templates built through the API or MCP are first-class entries in your workspace. Open them in the Studio, change anything, save. The agent can read your edits the next time it touches the template, so you can use the Studio for polish and the agent for the next bulk edit.

---

Ready to put this into production? [See pricing](https://www.courier.com/pricing) or [talk to our solutions team](https://www.courier.com/request-demo).


Build one multi-channel template and send it via the Courier CLI, REST API, or an AI prompt. Email, SMS, push, Slack, and in-app from one source.

Design and Send Messages: CLI, API, Prompts | Courier

Build a message in Elemental once and send it to email, SMS, push, Slack, and in-app from one template. Four surfaces work: prompts (fastest), the Courier CLI (scriptable), the REST API (production), and the Design Studio (visual fine-tuning). Covers brand setup, production concerns like idempotency and user identification, and channel routing.

Design and Send Your First Message: CLI, API, and Prompts

*Last updated: May 2026*

## What a journey is

![generic_journeys](//images.ctfassets.net/z7iqk1q8njt4/SC7dGKZHtjGrN7fJP9KcW/9a100cdd1ee0b666c38ee72064c4f212/generic_journeys.png?w=600)

A [Courier journey](https://www.courier.com/platform/journeys-customer-engagement-platform) is a multi-step messaging flow stored as JSON. Think of it as a state machine: you describe the sequence of things you want to happen for a user (send a welcome email, wait two days, check whether they signed in, send a follow-up if not), and Courier runs that sequence on the server so your application code doesn't have to keep track of where each user is in the flow.

Steps include sending a message, waiting, branching on conditions, fetching data from your API, calling an LLM, throttling, and exiting. Each step is a node. Nodes connect in a graph that runs per-user when the journey is invoked. The same journey definition handles thousands of users in parallel, each at a different step.

> Journeys are AI-powered orchestration for customer messaging. The whole point is that one definition, run server-side, handles the state and timing your application code would otherwise have to track itself.

For context on how the product evolved into this shape, see [Customer Journeys Then and Now](https://www.courier.com/blog/customer-journeys-then-and-now) and [Journeys: AI-powered orchestration for customer messaging](https://www.courier.com/blog/journeys-ai-powered-orchestration-for-customer-messaging-workflows). For the new AI node specifically, [Introducing the AI Node in Courier Journeys](https://www.courier.com/blog/ai-node-journeys) covers how LLMs slot into a flow.

The full node reference is in the [building journeys via API](https://www.courier.com/docs/platform/journeys/building-journeys-via-api) docs. The short version:

| Node | Purpose |
|------|---------|
| *trigger* | Entry point. *api-invoke* or event-based. An optional *schema* declares the data fields the journey expects on invoke. |
| *send* | Dispatches a journey-scoped notification template. The *message.template* field references a template that already exists under this journey. |
| *delay* | Pauses execution. *mode: "duration"* with an ISO 8601 duration (*PT2D* = 2 days), or *mode: "until"* with a datetime or a templated reference. |
| *branch* | Routes to different paths based on conditions. Every branch requires a *default* path with its own *nodes* array, so a run can't fall off the edge. |
| *fetch* | Calls an HTTP endpoint mid-run. Result merges into the journey's *data* per the *merge\_strategy*. |
| *ai* | Calls an LLM. Requires *model*, *user\_prompt*, and *output\_schema* (a JSON Schema). The model's response merges into *data.ai\_result.\** keyed by the schema's properties. |
| *throttle* | Caps concurrent runs at *scope: "user"*, *scope: "global"* (static cap), or *scope: "dynamic"* with a *throttle\_key* template. |
| *exit* | Ends the journey path. |

A journey body is *{ name, nodes, enabled?, state? }* on create. *state* is *DRAFT* or *PUBLISHED*; new journeys default to *DRAFT*. Server fields (the journey id, the minted node ids, timestamps, creator/updater) come back on the response. One naming quirk worth flagging: the docs and SDKs label the journey id path parameter as *{templateId}*. It is the journey id, not a notification template id; the journey-scoped notification template id is the second path segment as *{notificationId}*.

## The five-pass create flow

*POST /journeys* does **not** accept *send* nodes inline. Two constraints force a multi-pass flow. First, the API rejects send nodes at create time (*422 send nodes are not allowed at journey creation*) because every send has to reference a template that already exists, scoped to this journey. Second, a journey-scoped template referenced by a send has to be **published** before the journey replace lands; a send pointing at a draft template renders but no provider accepts it. So creating a journey end-to-end via the API takes five passes:

1. **Create the shell.** *POST /journeys* with the trigger, any non-send nodes (AI, branch, delay, exit), and no client-supplied node ids. The API mints the journey id and minted node ids; capture both.
2. **Create the journey-scoped templates.** *POST /journeys/{id}/templates* once per (touch, channel). Each template specifies a single *channel* and an Elemental *notification* body; the response includes the template id.
3. **Publish each template.** *POST /journeys/{id}/templates/{notificationId}/publish*. A send node referencing a template still in draft is a silent failure mode at runtime.
4. **Replace the journey with the wired body.** *PUT /journeys/{id}* with the full nodes array, send nodes now slotted into the right branches and referencing the template ids from pass 2. Supply the minted node ids on every node so PUT preserves identity instead of re-minting.
5. **Publish the journey.** *POST /journeys/{id}/publish* moves the draft to published. Invoking a draft *202*s but never delivers, so this step is required.

The stable Node (*@trycourier/courier* v7.11+), Python (*trycourier*), and Java (*com.trycourier:courier-java*) SDKs all expose the full journeys surface, including *journeys.create*, *journeys.replace*, *journeys.publish*, *journeys.invoke*, plus the parallel *journeys.templates.\** methods. The Courier CLI, as of 3.4.2, only ships *courier journeys list* and *courier journeys invoke*; the create, replace, publish, and template subcommands aren't in the CLI yet. Use an SDK or raw *curl* against the REST endpoints until they ship.

When you tell your agent "build a welcome flow that emails the user, waits 3 days, and sends an inbox follow-up if they haven't completed setup," the */courier-journeys-create* skill performs all five passes for you. You get one journey id back.

## Invoking a journey

Invocation is a separate *POST /journeys/{id}/invoke* call with *user\_id*, *profile*, and *data*. It returns *202* with *{ "runId": "1-..." }*. From the CLI: *courier journeys invoke <journey-id> --user-id <user> --profile '{...}' --data '{...}'*. A 202 means the run was accepted, not that anything has been delivered yet; check the message log for delivery status.

There is no public runs API today, so the human checkpoint after an invoke is [the message log](https://app.courier.com/data/logs/messages). Filter by recipient and time window, or by the notification template ids, to find what the run produced. The per-message *history* endpoint (*GET /messages/{message-id}/history*) is the authoritative source for delivery status: a trailing *type: SENT* event is the real success signal. AI nodes add real latency (budget about 30 seconds per node), so a *decider → copywriter → send* sequence often needs 60-90 seconds before the first history event lands.

## Working with nodes

The trigger node defines what data the journey accepts on invoke. Declaring fields upfront is worth the few extra lines: Studio's data picker treats declared paths as first-class fields, and any branch that reads a field has a known default value if the upstream populator (a fetch, an AI node, the invoke caller) doesn't overwrite it. A useful pattern is to add the activation flags a downstream branch will read to *schema.properties* with *default: false*, then let a fetch node overwrite them with *merge\_strategy: "overwrite"*.

Delay nodes use either a fixed *mode: "duration"* (ISO 8601, for example *P2D* or *PT5M*) or *mode: "until"* with a datetime or a templated reference like *{{data.deadline}}*. Throttle nodes accept *scope: "global"* for a static workspace-wide cap, *scope: "user"* for per-user, or *scope: "dynamic"* with a *throttle\_key* template for fan-out by any data field.

Branch nodes route on conditions and require an explicit *default* path. Conditions are positional string tuples, not objects: a binary atom is *[path, operator, value]* (operators include *is equal*, *is not equal*, *contains*, *greater than*, *less than*, and so on), a unary atom is *[path, operator]* (*exists*, *does not exist*), and groups wrap atoms in *{ AND: [...] }* or *{ OR: [...] }*. Path labels render in Studio and run logs, so write them as English ("Churn risk", "Default") rather than snake_case identifiers; the condition expressions still use snake_case for data paths.

A fetch node calls an HTTP endpoint mid-run with *method*, *url*, optional *body*, *headers*, *query\_params*, and a *merge\_strategy* that controls how the response combines with the journey's data. The result is available to later nodes through *{{data.\*}}* templated references and to branch conditions as *data.<field>*.

## AI nodes: required fields and how outputs are read

Every AI node must include three things: *model*, *user\_prompt*, and *output\_schema* (a valid JSON Schema). The API will accept an AI node missing *model* (no validation error) but the node silently no-ops at runtime: the invoke returns 202, no messages are produced, no errors are logged. Always set *model* to *claude-opus-4-7* (or another supported model) and *web\_search: false* unless you explicitly want the model to query the internet.

At runtime, each AI node writes its structured output into *data.ai\_result.\**, keyed by the schema's top-level property names. Downstream branches and template mustache read from *data.ai\_result.<field>*. This is the path that actually works. A previous version of the create skill recommended *refs.<node\_id>.output.<field>*; that path is undefined at runtime, so branches written against it fall through to the default and the bug only surfaces in production. Use *data.ai\_result.\** everywhere.

If two AI nodes run on the same path, the later one's *data.ai\_result.\** overwrites the earlier one's keys. In practice this is fine because branches usually read the decider's output before any copywriter runs, and copywriters write keys (*subject*, *body*) the branches never read.

## Pattern catalog

Real flows the agent can produce from a sentence:

- **Onboarding sequence.** Trigger on signup, send a welcome email immediately, delay 2 days, fetch setup state from your API, branch on whether setup was completed, send a follow-up if not.
- **Password reset.** Trigger on a *password-reset* event with a reset token in *data*, send one email, exit. The simplest journey worth building.
- **Abandoned cart.** Trigger on *cart-abandoned*, delay 1 hour, fetch cart status, branch on whether the cart was completed, send an email if not. Optionally chain another delay + push.
- **Escalation.** Trigger on *alert-fired*, send to the on-call engineer, delay 5 minutes, fetch acknowledgment status from your monitoring API, branch and escalate to the next person if not acknowledged. See the [alert notifications solutions page](https://www.courier.com/solutions/alert-notifications) for production examples.
- **Trial-to-paid upsell with AI personalization.** Trigger on trial start, send a quick-start touch (email + inbox), delay 2 days, fetch usage summary, run an AI decider that classifies engagement into a few buckets, branch on *data.ai\_result.classification*, run an AI copywriter on each branch to draft channel-appropriate copy, then send.

These are shapes, not templates you copy. The agent assembles the right node graph from your description. For longer treatments of specific shapes, see [How to Build B2B Customer Journeys](https://www.courier.com/blog/how-to-build-b2b-customer-journeys) and the common pitfalls in [5 Mistakes Teams Make Building Customer Journeys](https://www.courier.com/blog/customer-journey-mistakes). The first 48 hours of a user's life in your product is its own pattern, covered in [The First 48 Hours: Onboarding Notifications That Keep Users Around](https://www.courier.com/blog/onboarding-notifications-first-48-hours).

## Editing and iterating

*PUT /journeys/{id}* replaces the journey body wholesale. The replace shape is the full nodes array, not a patch. Two constraints to keep in mind: every send node must reference a journey-scoped template id that already exists (workspace-level templates created via *POST /notifications* are not usable inside a journey, even though both kinds return *nt\_*-prefixed ids), and supplying the minted node ids on each node preserves identity across PUTs. Omitting ids re-mints them, which is rarely what you want.

Reading a journey back uses *GET /journeys/{id}?version=draft* or *?version=published*. The unqualified endpoint returns 404 by design. The canonical-on-read shape differs slightly from what you POST: a bare condition atom comes back wrapped as *{ AND: [atom] }*, and an unlabeled default path comes back labeled *Default*. Don't file a round-trip bug; it's intentional.

The iteration loop is: describe the change in plain English ("Add a 1-hour delay before the second send, and skip the SMS for users with push enabled"), let the agent read the current journey, modify the node graph, PUT the new body, and inspect in the [Courier studio](https://app.courier.com/journeys/<id>). Publish when it looks right. The publish step is separate; the agent does not auto-publish unless you tell it to. Publish accepts an optional *{ "version": "vN" }* body to promote a prior version instead of the current draft, which is also the rollback path.

## Guardrails

Live journeys need guardrails because a wrong condition or a bad template can fan out to thousands of users fast.

**Default state is *DRAFT*.** Newly created journeys are drafts. Invoke a draft against a test user, inspect the messages in the log, then publish.

**Use a test segment.** If you trigger journeys from a backend event, gate the trigger on a feature flag or a user attribute (*is\_test\_user: true*) until you're confident.

**Set throttle nodes for fan-out.** A *throttle* node with *scope: "global"*, *max\_allowed: 100*, and *period: "PT1M"* caps the send rate so a bad branch doesn't blast your whole user base.

**Audit through the message log.** Every send within a journey shows up in [the message log](https://app.courier.com/data/logs/messages) with a *journey\_id* and *run\_id*. Filter by journey to see what fired.

**Version history is the rollback.** *POST /journeys/{id}/publish* with *{ "version": "v0" }* republishes a prior version. The journey id stays stable, so any in-flight runs continue under the version they started on.

[LaunchDarkly's Feature Workflows team](https://www.courier.com/use-cases/launchdarkly) uses Courier to coordinate flag releases across email and Slack, including approval flows that route to the right reviewer before a change goes live. They picked Courier for multi-channel routing, SOC 2 compliance, and the ability to drop into their existing Go SDK and provider stack.

## FAQs

### Why does the create flow need five passes?

Two API constraints stack. Send nodes are rejected at journey creation (*422 send nodes are not allowed*) because every send must reference a template that already exists scoped to this journey. And a send referencing a template still in draft renders fine but no provider accepts the resulting message. So the canonical order is: create the shell, create each template, publish each template, PUT the full journey body with sends wired in, then publish the journey. Once the journey is live, ongoing edits are one-step PUTs followed by an optional publish.

### Can AI edit a live journey safely?

The pattern that works: the agent edits the draft (via PUT), you review the diff, you publish manually with *POST /journeys/{id}/publish*. Letting the agent publish without a review step is fine for low-risk journeys (a transactional confirmation) but risky for marketing fan-outs. The journeys API supports both modes. Pick the trust level that matches the journey.

### How do I version journeys?

PUT replaces the current draft. *POST /journeys/{id}/publish* snapshots the current draft as a new published version. *GET /journeys/{id}/versions* lists all versions with paging. To roll back, republish an older version by passing *{ "version": "<id>" }* in the publish body.

### What happens when a user goes offline mid-journey?

Nothing. Journeys are server-side state machines. If a user is in a 7-day delay node, Courier resumes them at the end of the delay regardless of whether they were online. Send failures (a bounced email, a push to an uninstalled app) get logged but don't pause the journey unless you wire that behavior explicitly with a fetch and branch.

### Can I review and approve a journey before it goes live?

Yes. The default state on create is *DRAFT*. Anyone with workspace access can review in the Courier studio at *https://app.courier.com/journeys/{id}*. Publishing requires a separate *POST /journeys/{id}/publish* call, so the create-and-publish step can be split between the agent (creates draft) and a human (publishes).

### Are journey templates the same as notification templates I create outside a journey?

No. Journey-scoped templates live under */journeys/{id}/templates/\** and belong to one journey. Workspace-level notification templates (managed via */notifications*) are reusable across sends from your application code. Inside a journey, you reference a journey-scoped template; outside a journey, you reference a workspace-level template. Both use the same Elemental format, but the two ids are not interchangeable.

### Can the Courier CLI create journeys today?

Not yet. As of CLI 3.4.2, *courier journeys* ships *list* and *invoke* only. Use a Courier SDK (Node, Python, Java) or call the REST endpoints directly for create, replace, publish, and the journey-scoped template operations. The */courier-journeys-create* skill handles this automatically: it uses the SDK path for everything the CLI doesn't ship yet.

---

Ready to put what you've built into production? [See pricing](https://www.courier.com/pricing) or [talk to our solutions team](https://www.courier.com/request-demo).


Turn natural-language requirements into running customer journeys. JSON node model, branches, delays, AI nodes, throttle, version control.

AI-Built Customer Journeys: Node Model + API | Courier

A Courier journey is a JSON document describing a multi-step messaging flow with triggers, sends, delays, branches, fetches, AI nodes, and throttles. This chapter walks through the node model, how an AI agent generates a journey from English, common patterns for onboarding, password reset, abandoned cart, and escalation, and the guardrails that keep live journeys safe.

Journeys Built by AI

*Last updated: May 2026*

## Why agents need first-class messaging

![dual platform messages](//images.ctfassets.net/z7iqk1q8njt4/1rDgpfQ6ZuNL94H2IPHm7G/3cb2c9c0d4f37af46d4eea73d55f4a4c/Work.png?w=600)

An agent that can read and write inside your product but can't tell anyone outside of it is incomplete. The customer-support agent that resolves a refund still needs to email the receipt. The deployment agent that rolls back a release still needs to page the on-call engineer. The AI feature that finishes processing a long-running export still needs to push a notification when it's done.

Chat windows aren't enough. Real messaging means [email](https://www.courier.com/solutions/email-channel), SMS, [push](https://www.courier.com/solutions/mobile-channel), [Slack or MS Teams](https://www.courier.com/solutions/ms-teams-slack-channel), [in-app inbox](https://www.courier.com/platform/inbox), and the routing logic that picks the right one based on user preferences, channel availability, and quiet hours. Building that layer per-agent is a waste of time. Courier's [notification infrastructure](https://www.courier.com/platform/notification-infrastructure) gives any agent a complete messaging surface in a single integration through the MCP server (installed in Chapter 2).

## The Courier MCP server as an agent tool surface

An MCP "tool" is a typed function the AI tool can decide to call: it has a name, a parameter schema, and a return type. The model reads your prompt, decides which tool fits, fills in the parameters, and gets a structured response back. From the agent's perspective, calling *send\_message* to dispatch a notification is no different from calling any other tool in its loop. The MCP server handles request signing and response formatting transparently, and your Courier API key (passed by your AI tool as an *api\_key* header on every call) determines which workspace the calls land in.

The Courier MCP server exposes Courier's API as 109 typed tools across send, messages, profiles, notifications, lists, audiences, brands, journeys, providers, tenants, automations, bulk operations, device tokens, and audit events. An agent that connects to *mcp.courier.com* gets tools like:

- *send\_message*, *send\_message\_template*, *send\_message\_to\_list*. Dispatch a notification.
- *create\_notification*, *publish\_notification*, *put\_notification\_content*. Build and ship templates.
- *create\_or\_merge\_user*, *get\_user\_profile\_by\_id*, *patch\_profile*. Manage user identity.
- *subscribe\_user\_to\_list*, *bulk\_subscribe\_to\_list*, *list\_lists*. Manage subscriptions.
- *list\_journeys*, *invoke\_journey*. Trigger existing journeys.
- *list\_messages*, *get\_message*, *cancel\_message*. Inspect and recall deliveries.

The agent picks tools by name and fills in parameters from the schema. There's no prompt engineering needed to teach the agent how to use Courier. The tool descriptions and parameter schemas are part of the MCP protocol.

Two scope notes worth flagging up front. First, creating journey definitions today happens through the [REST API](https://www.courier.com/docs/platform/journeys/building-journeys-via-api) or a stable Courier SDK, not through MCP or the CLI's journey subcommands. Agents can *list\_journeys* and *invoke\_journey* over MCP, which covers the most common runtime use case: pick a pre-built journey and run it for a user. The */courier-journeys-create* agent skill handles the build-side flow via the SDK path. Second, connecting channel providers (Gmail OAuth, Twilio API key, Slack bot token, and so on) is done through the [Courier dashboard](https://app.courier.com) once; the MCP server then handles the runtime sends.

For deeper reads on this pattern, see [How to Send Notifications from an AI Agent with Courier's MCP Server](https://www.courier.com/blog/send-notifications-ai-agent-courier-mcp) and [Courier MCP: Let your AI agent handle customer messaging end to end](https://www.courier.com/blog/courier-mcp-let-your-ai-agent-handle-customer-messaging-end-to-end).

## Sending notifications from inside an agent loop

The minimum agent send call looks like this in Python with the [Anthropic SDK's native MCP support](https://docs.claude.com/en/api/messages):

```python
from anthropic import Anthropic
import os

client = Anthropic()
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    mcp_servers=[{
        "type": "url",
        "url": "https://mcp.courier.com",
        "name": "courier",
        "authorization_token": os.environ["COURIER_API_KEY"],
    }],
    messages=[{
        "role": "user",
        "content": "Email alex@example.com that their export is ready at https://app.example.com/exports/ex_123."
    }],
)
```

The agent reads the request, picks *send\_message*, fills in the recipient and message body, and the email goes out. No glue code. No template lookup. The agent does the work. The Courier MCP server reads the API key from the request authorization headers your SDK passes; whatever transport your client uses, the same key (the one you'd use against the REST API) gets the agent into the right workspace.

For more complex flows ("notify the user, then if they don't open it in an hour, follow up with a push"), the agent reaches for *invoke\_journey* to trigger a pre-built [customer journey](https://www.courier.com/solutions/customer-journeys) instead of building the loop in your application code. Chapter 4 covers the journey node model and how to create journeys.

## Identity, tenants, and user preferences

Agents that send messages on behalf of users need to know who the user is. Courier supports two identity models:

**User-scoped.** Pass a *user\_id* on the send. Courier stores the profile (email, phone, push tokens, Slack ID) and preferences against that user. Subsequent sends to the same *user\_id* find the right channels automatically. Profiles are managed with *create\_or\_merge\_user*, *patch\_profile*, and *replace\_profile* from the MCP tool list; the same surface lives at *POST /profiles/{user\_id}* on the REST API, with *POST* merging and *PUT* replacing.

**Tenant-scoped.** For B2B products where users belong to organizations, set a *tenant\_id* on the send. Templates, preferences, and branding can be scoped to a tenant. An agent operating on behalf of a tenant's user sees only that tenant's data.

Preferences are user-controlled and managed through Courier's [preferences management](https://www.courier.com/platform/preferences-management) layer. If a user opts out of marketing email, your agent's send call respects that automatically. The send call doesn't fail; it just skips the email channel for that user and continues to the next channel in the routing config (or returns a filtered status if no channel applies).

For any send that should be safe to retry, include an *Idempotency-Key* HTTP header on the request. Courier deduplicates against the stored response, so a network retry doesn't produce a duplicate message. Two notes from the [agent quickstart](https://www.courier.com/docs/tools/agent-quickstart): replaying a key that previously errored returns the stored error unchanged, and the Node SDK's *idempotencyKey* request option silently no-ops, so pass the key in *headers* instead.

## Logging and observability

![analytics](//images.ctfassets.net/z7iqk1q8njt4/6SviZWctcFo8TJM4JVAOsc/2123bacd190d326a174bae9a31028b92/analytics.png?w=600)

Every agent send shows up in the [message log](https://app.courier.com/data/logs/messages) with:

- *requestId*. Stable ID for the send returned by the send call.
- *user\_id* and *tenant\_id*. Who it was for.
- Channel breakdown. Which providers were tried, which succeeded.
- Status events. Rendered, sent, delivered, opened, clicked, bounced.

For agent-initiated sends specifically, set a *metadata* field on the send with an agent identifier and the prompt that triggered the call. That separates agent traffic from your application's transactional sends and makes audits easier. The aggregate per-message truth is *GET /messages/{message-id}/history*; a trailing *type: SENT* event is the real delivery confirmation. [Audit Notifications with Cursor or Claude Code](https://www.courier.com/blog/notification-audit) walks through reviewing what an agent has sent across a workspace.

> Agents that send messages need the same observability surface as the rest of your stack: structured logs, channel breakdowns, and the ability to filter by who initiated the send. The MCP server treats agent-initiated traffic as first-class, not as a side channel.

## Safety

Agents can fan out fast. Three controls keep them safe.

**Rate limits.** Use *throttle* nodes in journeys or set per-workspace send caps in your Courier dashboard. Courier rejects sends that exceed the cap with a clear error, so the agent can retry with backoff rather than retrying blindly.

**Approval gates.** For high-stakes sends (a mass announcement, a refund confirmation), have the agent build the template or journey in *DRAFT* state and let a human publish. Notification publish, journey publish, and journey-scoped template publish are each separate tool calls on the MCP server (*publish\_notification*, *publish\_journey*, and the template-publish flow), so the create-and-publish split is supported natively.

**Dry-run mode.** Most send endpoints accept a *dry\_run: true* parameter. The agent runs through the routing and rendering, returns what it would have sent, and skips the actual dispatch. Use this for any send the agent initiates without explicit human approval until you trust the behavior. For a worked example, [Human-in-the-loop for AI payment agents](https://www.courier.com/blog/human-in-the-loop-ai-agent-notifications) shows how a payment-handling agent uses approval notifications to confirm high-stakes actions before they fire.

## FAQs

### Can my agent message arbitrary users?

Only users in the workspace your API key belongs to. The MCP server scopes calls to the authenticated workspace (every tool call carries the *api\_key* your client passed at connection time). An agent can't reach users outside it. Within the workspace, the agent can send to any user the API key has access to, which means you should scope keys carefully if you're running multi-tenant. Generate separate keys per agent or per environment so you can revoke individually.

### How do I log what an agent sent and why?

Set a *metadata* object on the send call with the agent's identifier, the prompt that triggered the send, and any reasoning the agent recorded. The metadata persists with the message log and is searchable. For high-volume agent traffic, pipe the Courier webhook stream into your observability tool for full traceability.

### Can agents respect quiet hours and user preferences automatically?

Yes. User preferences (channel opt-ins, time zone, frequency caps) are stored on the user profile. Every send call checks them. If a user has opted out of a channel, Courier skips that channel and continues through the routing fallbacks.

### How do I cap an agent's send rate?

Two options. Set a workspace-level rate limit in the Courier dashboard (sends per second, per minute, per hour). Or wrap the agent's sends in a journey with a *throttle* node. The journey approach gives you per-user, per-segment, or global throttles with a single config.

---

Ready to put this into production? [See pricing](https://www.courier.com/pricing) or [talk to our solutions team](https://www.courier.com/request-demo).


Give autonomous agents real messaging tools. Send, route, log, rate-limit, and apply approval gates from inside any agent loop with Courier MCP.

AI Agent Messaging Tools: MCP, Identity, Safety | Courier

Autonomous agents need a real messaging surface (email, SMS, push, Slack, in-app inbox) not just a chat window. This chapter shows how to connect the Courier MCP server as an agent tool, handle identity and preferences, log every send for observability, and apply rate limits, approval gates, and dry-run mode to keep agent traffic safe.

Giving Autonomous Agents Messaging Tools

*Last updated: May 2026*

## AI customer-support agents that close the loop

A customer-support agent that can read tickets, look up account state, and answer a customer is only half the job. The other half is making sure the customer hears the resolution. A refund processed in the agent's loop needs an [email](https://www.courier.com/solutions/email-channel) receipt. An account change needs a confirmation. A reset password needs a delivery to the user's inbox or phone. [Trusted Health](https://www.courier.com/use-cases/trusted-health-workforce-management) uses Courier for workforce management notifications in healthcare staffing.

The pattern: agent resolves the ticket, agent calls *send\_message* through the Courier MCP, the customer gets the notification. The agent's logs and Courier's message logs together give you a complete record of what happened on the support side and what reached the customer.

For agents that handle high volume, route low-priority confirmations through email and reserve SMS for urgent updates. The user's preference center settings carry through automatically.

## Autonomous workflow agents

![push_notification](//images.ctfassets.net/z7iqk1q8njt4/2brAQ0jr6eRZndtHMDywYN/35959bb48d63f146fa85b19bf1e730db/push_notification.png?w=600)

DevOps agents that triage [alert notifications](https://www.courier.com/solutions/alert-notifications). Ops agents that handle scheduled runs. Internal-tools agents that approve access requests. These are agents acting on infrastructure, with humans in the loop for review or escalation. [CircleCI](https://www.courier.com/use-cases/circleci-developer-notifications) uses Courier for developer notifications across its platform.

The send patterns here are different from customer-facing:

- **Page on-call.** Agent triggers an escalation journey. Journey sends to the on-call engineer, waits 5 minutes, branches on whether the alert was acknowledged, escalates if not.
- **Notify a Slack channel.** Agent posts a structured [Slack message](https://www.courier.com/solutions/ms-teams-slack-channel) with block-kit actions. A teammate clicks "approve" or "decline" and the agent reads the response.
- **Daily digest.** Agent compiles its overnight activity and sends a single morning email to the owning team. [LaunchDarkly](https://www.courier.com/use-cases/launchdarkly) uses similar workflow notifications to coordinate feature release approvals.

Workflow agents benefit most from journeys (multi-step flows with delays and branches) rather than single sends. The journey holds the state machine so the agent doesn't have to. See Chapter 4 for the journey node model and Chapter 5 for the agent-side patterns that drive them.

## In-product AI features

Features built on top of Claude or another LLM often need to message users when something finishes. A long-running export. A document analysis. A scheduled summary. The agent doing the work calls Courier to deliver the result through the right [channel for the moment](https://www.courier.com/solutions/in-app-channel). [Twilio](https://www.courier.com/use-cases/twilio) unified notifications across its developer platform on the same primitives.

The notification scaffolding (channel routing, preference compliance, delivery logging) is the same as any other product message. What's different is the trigger: instead of an event in your application code, it's the agent finishing a task.

## Build vs. buy for AI-native messaging

Let's talk honestly about what it takes to build this from scratch, because most teams underestimate the surface area until they're months in. You need to pick providers for every channel (SendGrid or Postmark for email, Twilio for SMS, FCM for push, Slack for chat) and write per-provider client code and credential storage for each. You need a template system that renders the same message to multiple channels, preference storage per user, channel routing and fallback logic, and a webhook listener for delivery events and bounces. You need a journey engine if you want multi-step flows (or you skip it and use cron jobs, which break in subtle ways). And to make any of this AI-accessible, you need to expose the whole thing as MCP tools so your agent can call it.

That's a 2-engineer team for 6-12 weeks to ship a basic version, then ongoing maintenance for every new provider and every preference rule. The "expose as MCP tools" step alone is a multi-week project if you've never built an MCP server. [Best Ways to Build Notification Infrastructure in 2026](https://www.courier.com/blog/best-ways-to-build-notification-infrastructure) walks through this in more detail.

> "There are very few products we're using that I'm so excited about... The problem is solved."
>
> **Pierre-Camille Hamana, founder, Hospitable.com** — after replacing an in-house notification system (codenamed Churchill) that had taken three engineers full-time for three months plus a CTO managing the project

Buying means the providers, templates, preferences, routing, journeys, and MCP tool surface are already there. You connect the providers you want from the Courier dashboard, point your agent at *mcp.courier.com* with your API key in the *api\_key* header, and skip the build entirely. The time saved is engineering time you'd otherwise spend on plumbing instead of your product's actual differentiator.

The case for building is real for a small number of products: extremely high volume where margins matter, regulated industries with custom audit requirements, or messaging that's so core to the product that it's part of the differentiation. For everyone else, buy.

## Where Courier fits

For a broader market scan of the category, see [5 Best Platforms for Product Messages in 2026](https://www.courier.com/blog/best-product-messaging-platforms).

Courier sits between pure notification infrastructure (developer-focused tools like [Knock](https://knock.app/) and [Novu](https://novu.co/)) and customer engagement platforms (Braze, Klaviyo, Intercom). Courier's positioning is infrastructure-grade reliability with tools non-technical people can actually use, plus a developer-first surface area (CLI, MCP server, typed SDKs, clean docs) that the AI-native shifts in this guide depend on.

A few things Courier specifically brings to AI use cases:

- **MCP server** at *mcp.courier.com* that exposes 109 typed tools, so an AI agent can read, write, and modify the messaging system, not just send to it.
- **Bring Your Own Provider (BYOP).** Courier orchestrates on top of your existing providers (Twilio, Resend, FCM, APNs, Slack, MS Teams). Swap or add providers without code changes.
- **Cross-channel templates in one place.** Transactional, product, and marketing notifications managed in one platform across [email](https://www.courier.com/solutions/email-channel), [push](https://www.courier.com/solutions/mobile-channel), SMS, [in-app inbox](https://www.courier.com/platform/inbox), [Slack and MS Teams](https://www.courier.com/solutions/ms-teams-slack-channel).
- **Built-in safeguards and governance.** Frequency capping, [preference management](https://www.courier.com/platform/preferences-management), compliance guardrails, automatic failover when a provider goes down.
- **Drop-in UI components.** Inbox, Preferences, Toasts. Production-ready, saves months of build time.

For where Courier honestly isn't the best fit: if you genuinely only ever need one channel, direct integration with that channel's provider may be simpler than running an orchestration layer.

## Getting started

The fastest path: create a free Courier account at [courier.com](https://www.courier.com/), connect Gmail as your first provider through the [Courier dashboard](https://app.courier.com) (the dashboard walks you through Gmail's OAuth flow in your browser, no API key required), install the Courier MCP server in your AI tool with the one-line command from Chapter 2 (pass your Courier API key as an *api\_key* header), and ask your agent to build and send a test message.

You'll have a working AI-native messaging setup in under 15 minutes. From there, add the providers you actually want, generate the templates your product needs, install the [Courier skills](https://www.courier.com/docs/tools/courier-skills) bundle so the agent has Courier-specific guidance for common tasks, and let the agent handle the rest. [The Notification Platform Developers Choose](https://www.courier.com/blog/notification-platform-for-developers) covers what teams typically build first.

For deeper reference, see the [Courier docs](https://www.courier.com/docs), the [AI onboarding guide](https://www.courier.com/docs/tools/ai-onboarding), the [agent quickstart](https://www.courier.com/docs/tools/agent-quickstart), the [Sending overview](https://www.courier.com/docs/platform/sending/sending-overview), and the [Journeys API reference](https://www.courier.com/docs/platform/journeys/building-journeys-via-api). Agents can pull a machine-readable index of the docs from [*courier.com/docs/llms.txt*](https://www.courier.com/docs/llms.txt) on their own when they need to discover capabilities mid-task.

## FAQs

### How fast is integration in a real codebase?

For a new product without existing messaging code, an agent-driven install takes about an hour to go from zero to a sent message: account, MCP install, provider connection in the dashboard, first template, first send. For an existing codebase with current providers and templates, Courier can sit alongside the existing system while you migrate flows piece by piece. Most teams report 1-2 weeks of incremental adoption rather than a single migration.

### What does the free tier cover for AI agents?

A free tier with monthly send volume that's enough to run an AI agent in development and through small-scale production. All channels and features are included; the constraint is volume. If you cross the limit, you move to a paid plan that scales with volume. See [pricing](https://www.courier.com/pricing) for current numbers, or [talk to our solutions team](https://www.courier.com/request-demo) if your usage is harder to estimate.

### Where does Courier fit in the broader notification platform category?

Courier sits between developer-focused notification infrastructure (Knock, Novu) and customer engagement platforms (Braze, Klaviyo, Intercom). Distinguishing factors: BYOP (Courier orchestrates on top of providers you already use rather than being a provider itself), an MCP server that exposes 109 typed tools for AI agents, and a single platform that covers transactional, product, and marketing notifications across every major channel. For a head-to-head walkthrough of the category, see [5 Best Platforms for Product Messages in 2026](https://www.courier.com/blog/best-product-messaging-platforms).

### Can I migrate existing notification logic into Courier incrementally?

Yes. Most teams start with one channel or one notification type, point that flow at Courier, and leave the rest on the existing system. Courier's template format accepts Elemental, HTML, and plain text, so you can move existing templates over without rewriting them.

---

Ready to put this into production? [See pricing](https://www.courier.com/pricing) or [talk to our solutions team](https://www.courier.com/request-demo).


AI support agents, workflow agents, in-product AI features. Build vs buy, comparison to Knock/Novu/OneSignal, and how to start in 15 minutes.

AI Notifications: Use Cases, Build vs Buy | Courier

Concrete use cases for AI-native messaging (customer-support agents, workflow agents, in-product AI features), an honest build vs buy analysis, a comparison to Knock, Novu, and OneSignal for AI workloads, and the fastest path to a working setup. Closes with getting-started steps and migration guidance for teams with existing notification code.

Use Cases and Why Courier

how to build product notifications with AI

Create notifications with AI. Install Courier, design messages from a prompt, build journeys from natural language, and give agents tools to send.

How to Create Notifications with AI | Courier

Building product messages used to be slow: schemas, templates, providers, retry logic, preferences. AI changes the economics. Anyone shipping a product can now stand up multi-channel messaging in minutes, design and send a first message through a prompt, generate user journeys from English, and hand messaging tools directly to autonomous agents. This guide walks through all four shifts, with working code where it counts.

How to Create Notifications with AI

Highlights

Contents

Products

Solutions

Platform