Courier MCP Server

Add a user to a tenant.

Delete all list subscriptions for a user.

Delete a user's preference for a specific subscription topic, reverting it to the topic's default status.

Delete a specific push token for a user.

Get all list subscriptions for a user.

Get a user's preference for a specific subscription topic.

Get a user's notification preferences (subscriptions, opt-outs, channel preferences).

Get a user profile by their ID. Returns profile data including email, phone, and custom properties.

Get a specific push/device token for a user.

List all push/device tokens for a user.

List all tenants a user belongs to.

Remove a user from a tenant.

Update a user's preference for a specific subscription topic (opt in, opt out, or set channel preferences).

Add users to an existing bulk job.

Add a user to multiple tenants at once. A custom profile can be supplied per tenant.

Add multiple push/device tokens for a user in one request. Overwrites matching existing tokens.

Replace a user's complete set of preference overrides in one request. The topics in the body become the recipient's entire override set: listed topics are created or updated, and every existing override not included is reset to its topic default. An empty `topics` array clears all overrides. Validation-atomic (all-or-nothing).

Replace all subscribers on a list with the given recipients.

Additively create or update a user's preferences for one or more topics in a single request. Only the topics in the body are touched; existing overrides for other topics are left untouched. Partial-success: valid topics are written and returned in `items`, unapplicable ones collected in `errors`.

Create a new bulk job for sending messages to multiple recipients. Workflow: create_bulk_job → add_bulk_users → run_bulk_job.

Get the status of a bulk job.

List the users in a bulk job.

Run a bulk job, triggering delivery to all added users.

Create or replace a tenant. Tenants represent organizations or groups that users belong to.

Delete a tenant by its ID.

Remove default notification preference for a topic from a tenant.

Delete a tenant notification template. Returns 204 on success, 404 if the template does not exist for this tenant.

Get a tenant by its ID.

Get a tenant notification template association by template ID.

Get a specific version of a tenant notification template (e.g. latest, published, or v1).

List notification templates configured for a tenant.

List users associated with a tenant.

Set the default notification preference for a subscription topic on a tenant. This controls tenant-level defaults — it does NOT set per-user preferences (use the user preferences API for that). The topic_id must already exist as a subscription topic in the workspace; a 404 means the topic has not been created yet. Example: { tenant_id: "acme", topic_id: "marketing-updates", status: "OPTED_IN", has_custom_routing: true, custom_routing: ["email", "push"] }.

Create or replace a push/device token for a user.

Replace (update) a journey draft. Full document replacement — include all nodes and properties in the body, the trigger included; anything omitted is deleted. The journey stays a draft; making the change live is a separate step this tool cannot perform. This is where send, delay, branch and exit nodes are added, and send node template IDs must already be scoped to this journey. The result carries a "verification" object read back from the server after the write — check it every time. verified:true means what you asked for is what saved. verified:false names what did not: "fieldMismatches" for node fields that failed to land, "nodeCountMismatch" for a node dropped or added, and "unknownTemplateReferences" for a send node pointing at a template id this journey does not have — almost always a mistyped id, so re-copy it from the create_journey_template or get_journey response it came from. Fix the specific thing named and send the corrected document. Re-sending an identical call changes nothing, and every replace_journey overwrites the whole draft again. An "errorKind" of "unauthorized" means the write itself succeeded and only the read-back was refused: report that as unconfirmed, never as a failed write.

Replace the draft of a journey-scoped notification template. Full document replacement. Call publish_journey_template afterwards to make it live.

Replace a notification template entirely (full document PUT). The template stays a draft; making it live is a separate step this tool cannot perform.

Replace a preference section. Full document replacement; missing optional fields are cleared. Topics attached to the section are unaffected.

Replace a topic within a section. Full document replacement; missing optional fields are cleared.

Fully replace a user profile (PUT). All existing data is overwritten; include every field you want to keep.

Replace a routing strategy. Full document replacement; missing optional fields are cleared.

Create or replace a tenant notification template (draft unless published is true).

Create a new journey. Always created as a draft; making it live is a separate step this tool cannot perform. Send two nodes: the trigger, and an exit node last. Both are required — a create with no exit node is rejected, and the API reports that as "exit node must be the last node in the journey" even when no exit was sent at all. Send and delay nodes are added afterwards by replace_journey, once journey-scoped templates exist. Node ids are server-generated; do NOT include an id field. Example: { name: "Welcome Journey", nodes: [{ type: "trigger", trigger_type: "api-invoke" }, { type: "exit" }], enabled: true }. The result carries a "verification" object read back from the server after the write — check it every time. verified:true means what you asked for is what saved. verified:false names what did not: "fieldMismatches" for node fields that failed to land, "nodeCountMismatch" for a node dropped or added, and "unknownTemplateReferences" for a send node pointing at a template id this journey does not have — almost always a mistyped id, so re-copy it from the create_journey_template or get_journey response it came from. Fix the specific thing named and send the corrected document. Re-sending an identical call changes nothing, and every replace_journey overwrites the whole draft again. An "errorKind" of "unauthorized" means the write itself succeeded and only the read-back was refused: report that as unconfirmed, never as a failed write.

Create a notification template scoped to a journey. Always created as a draft; making it live is a separate step this tool cannot perform. The template can then be referenced in journey send nodes. content.elements must be wrapped in a channel block — the API rejects bare elements. Example: { journey_id: "j-abc", channel: "email", notification: { name: "Welcome Email", tags: [], brand: null, subscription: null, content: { version: "2022-01-01", elements: [{ type: "channel", channel: "email", elements: [{ type: "text", content: "Hello!" }] }] } } }. The result carries a "verification" object confirming the new id is really present on the journey. verified:true means the id in this response is safe to reference from a send node. verified:false means it is not visible yet — re-read the journey before referencing it, and do not create a second template to work around it. An "errorKind" of "unauthorized" means the template was created and only the check was refused.

Get a journey by ID. Pass version=draft to retrieve the working draft, or version=vN for a historical version. Defaults to published.

Get a journey-scoped notification template by notification ID. Pass version=draft to retrieve the working draft (required before the template has been published). Defaults to published.

Fetch the elemental content of a journey-scoped notification template. Pass version=draft for the working draft, or vN for a historical version. Defaults to published.

List published versions of a journey-scoped notification template, ordered most recent first.

List notification templates scoped to a journey. Journey-scoped templates can only be used by send nodes within the same journey. Call this to discover template IDs before wiring send nodes in replace_journey.

List published versions of a journey, ordered most recent first.

Create a V2 notification template. name is required. Content may be provided inline or set separately afterwards. A newly created template is a draft; making it live is a separate step this tool cannot perform. Link a routing strategy via notification.routing.strategy_id to control which channels are used. Example: { notification: { name: 'welcome-email', tags: [], brand: null, subscription: null, routing: { strategy_id: 'rs_01abc' }, content: { version: '2022-01-01', elements: [] } } }.

Retrieve a notification template by ID. Optionally request draft, published, or a version such as v001.

Get the published content blocks of a notification template.

Get the draft (unpublished) content blocks of a notification template.

Delivery funnel for ONE notification template over time: sent, delivered, opened, clicked, errors and undeliverable, per provider and channel, in time buckets. Choosing the window — supply EITHER `lookback` OR `start` and `end` together, NEVER both. Supplying both is rejected. For a relative window like 'the last week', `lookback` alone is the whole answer: do not also pin `start` and `end`. Default is the last 30 days by day. Fine granularities cover shorter windows: HOUR spans at most 7 days and DAY at most 90. How far back a workspace may look also depends on its plan; a request reaching further back is refused with a payment error, which means the plan does not cover that window, NOT that there is no data. A coarser granularity can reach further back than a fine one. Reading the numbers correctly: - The first four counters are NESTED, not separate groups. Every delivered message is also counted in sent, every opened one in delivered, every clicked one in opened. So sent >= delivered >= opened >= clicked always. Report rates (delivered/sent) or the counters themselves. Do NOT add them together — the total is meaningless. And sent minus delivered is NOT a failure count; it is only 'did not reach the delivered stage', for any reason. - errors and undeliverable are counted separately and OVERLAP the funnel: a message that failed on one provider and succeeded on a retry appears in both errors and sent. They are not a remainder and do not complete a total. - Every counter is a count of distinct MESSAGES, not of events. A message that errored three times counts once in errors. - A bucket's `data` array holds one entry per provider and channel. To get a bucket total, add up the entries in that array — that is the only sum that means anything here. Note that rows for Courier's own built-in email sender are excluded, so these entries can add up to less than the workspace's true volume. What the buckets mean: - A message is counted in the bucket it was ENQUEUED in, not when the event happened. An open today of a message sent last Tuesday is counted in last Tuesday's bucket. So a past bucket can still change: yesterday's `opened` may be higher when you ask again tomorrow. - Results are cached for up to an hour and the pipeline adds its own lag, so a message sent minutes ago is expected NOT to appear yet. Never tell a user a just-sent message is missing; say the data has not caught up. - Read the window off the response's `start` and `end`, not off what you asked for. The API widens the window to whole buckets and returns the boundaries it actually used. - Quiet buckets are returned with an empty `data` array, so the series has no gaps. - An unknown template id returns an all-empty series rather than an error, and messages sent without a template never appear here at all. An empty result is not proof a template is unused — check that the id is right before concluding anything from it. - Because of that, a NOT FOUND / 404 error is never about the template id. It means the metrics endpoint itself could not be reached, which is an infrastructure or configuration problem on Courier's side. Say that the metrics service is unreachable and that someone should be told; do NOT tell the user to check or correct their template id, which sends them to fix something that was never wrong.

List checks for a notification submission.

List version history for a notification template.

Update check statuses for a notification submission.

Archive a journey. Archived journeys cannot be invoked but existing runs continue to completion.

Archive a journey-scoped notification template. Archived templates cannot be sent.

Archive a notification template by ID.

Archive a preference section. The section must be empty: delete its topics first, otherwise the request fails with 409.

Archive a topic within a section.

Archive a send request and all its associated messages by request ID.

Archive a routing strategy. The strategy must not have associated notification templates; unlink all templates before archiving.

Create a preference section in your workspace. The section id is generated and returned. Add topics afterwards with create_preference_topic.

Create a subscription preference topic inside a section. The topic id is generated and returned. Fails with 404 if the section does not exist.

Retrieve a preference section by id, including its topics.

Retrieve a topic within a section. Returns 404 if the section or topic does not exist, or the topic belongs to a different section.

List the workspace's preference sections. Each section embeds its topics.

List the topics in a preference section.

Create a new provider (integration) configuration. Once routing strategies or notification templates reference this config, credential or settings mistakes can affect live sends—confirm provider key and settings against list_provider_catalog before saving. The provider field must be a known Courier provider key.

Delete a provider configuration. Returns 409 if the provider is still referenced by routing or notifications.

Fetch a single provider configuration by ID.

List available provider types from the catalog with their configuration schemas.

Replace an existing provider configuration. Full replacement — retrieve current config with get_provider first; omitted optional fields are cleared. Changing API keys or settings affects live delivery if this integration is in use.

Publish the current draft of a journey, making it live and invokable. Pass version to roll back to a prior published version instead of publishing the draft. Returns 404 if there is no draft to publish.

Publish the current draft of a journey-scoped notification template. Optionally pass version to roll back to a prior version.

Publish a notification template, making it available for sending. Must be called before send_message_template unless the template was created with state: 'PUBLISHED'. Publishes the current draft by default; pass version (e.g. 'v001') to publish a specific historical version. Returns 204 on success.

Publish the workspace's preferences page. Takes a snapshot of every section with its topics under a new published version, making the current state visible on the hosted preferences page.

Publish a version of a tenant notification template.

Replace the elemental content of a journey-scoped notification template. Overwrites all elements. The template stays a draft; making it live is a separate step this tool cannot perform.

Set locale-specific content overrides for a journey-scoped notification template. Each element override must reference an existing element by its id.

Replace the elemental content of a V2 notification template. Overwrites all elements. Use channel elements to target specific channels. Multi-channel example: elements: [{ type: "channel", channel: "email", elements: [{ type: "meta", title: "Hello" }, { type: "text", content: "Email body" }] }, { type: "channel", channel: "push", elements: [{ type: "meta", title: "Hello" }, { type: "text", content: "Push body" }] }, { type: "channel", channel: "inbox", elements: [{ type: "text", content: "Inbox plain text only" }] }]. The template stays a draft; making it live is a separate step this tool cannot perform.

Update a single element within a V2 notification template. The template stays a draft; making it live is a separate step this tool cannot perform.

Set locale-specific content overrides for a V2 notification template. Each element override must reference an existing element by its id. Example for Spanish locale: { notification_id: "nt_01abc", locale_id: "es", elements: [{ id: "elem_meta_1", title: "Restablecer contraseña" }, { id: "elem_text_1", content: "Haga clic en el enlace para restablecer su contraseña." }] }. The template stays a draft; making it live is a separate step this tool cannot perform.

Delete an audience by its ID.

Get an audience by its ID, including its filter definition.

List all members of an audience.

Create or update an audience with a filter definition.

Create a new brand. The API requires settings — omitting it returns a 400. If you do not have specific brand colors, omit settings and a safe default will be used automatically (black primary, white secondary). Example: { name: "Acme", settings: { colors: { primary: "#1a73e8", secondary: "#ffffff" } } }.

Delete a brand by its ID.

Get a brand by its ID.

Replace an existing brand with new values.

Cancel a running automation by its cancelation_token. This invokes a second ad-hoc automation with a single cancel step. The token must match the cancelation_token set when the original automation was started. Note: spelling is "cancelation_token" (single "l").

Cancel journey runs. Supply EXACTLY ONE of cancelation_token (cancels every run associated with the token) or run_id (cancels a single run). Cancelation is idempotent: a run that already finished or was already canceled is left unchanged.

Cancel a message that is currently being delivered. Returns the message details with updated status.

Cancel a notification template submission.

Create a routing strategy defining how notifications are delivered across channels and providers.

Retrieve a routing strategy by ID. Returns the full entity including routing, channels, and providers.

List routing strategies in the workspace. Returns metadata only; use get for full details.

List notification templates associated with a routing strategy. Useful for checking linked templates before archiving.

Send a message to a user using inline title and body content (no template). Optionally specify routing channels. API reference: https://www.courier.com/docs/api-reference/send/send-a-message.

Send a message to a user using a published notification template. Only published templates can be sent; publishing a draft is a separate operation. Example: { user_id: "user-123", template: "nt_01abc123", data: { name: "Alex", resetUrl: "https://app.example.com/reset" } }.

Send a message to all subscribers of a list using inline title and body content. API reference: https://www.courier.com/docs/api-reference/send/send-a-message.

Send a message to all subscribers of a list using a notification template.

Invoke an ad-hoc automation with inline steps. Valid step actions: send, send-list, delay, cancel, update-profile, invoke, fetch-data. To cancel a previously started automation, use the cancel_automation tool instead.

Invoke an automation run from an existing automation template. template_id refers to an existing automation template in the workspace. Example: { template_id: "auto-onboarding", recipient: "user-123", data: { plan: "pro" } }.

Invoke a journey run from a journey template. template_id refers to an existing journey template in the workspace. Example: { template_id: "j-onboarding", user_id: "user-123", data: { plan: "pro" } }.

Get the full details and status of a single message by its ID.

Get the rendered content (HTML, text, subject) of a previously sent message.

Get the event history for a message, showing each step in the delivery pipeline (enqueued, sent, delivered, etc.).

Get a specific audit event by its ID.

List audit events in the workspace. Useful for tracking API usage and changes.

Partially update a user profile via JSON Patch (RFC 6902). Use add/replace/remove operations on specific profile paths.

Apply a JSON Patch (RFC 6902) to a specific push token.

Subscribe a user to a list. Creates the list if it doesn't exist.

Subscribe a user to one or more lists. Creates lists that do not exist.

Append subscribers to a list without removing existing subscribers.

Get all subscribers of a list.

Get a translation for a specific locale (e.g. "en_US", "fr_FR").

Create or update a translation for a specific locale. API reference: https://www.courier.com/docs/api-reference/translations/update-translations-by-locale.

Remove a user from all tenants.

List all audiences in the workspace.

List automation templates in the workspace, returning each template_id and its version state. Optionally filter by version.

List all brands in the workspace.

Get the Courier SDK installation guide for a specific platform. For client-side SDKs (React, iOS, Android, Flutter, React Native), also generates a sample JWT.

Create or update a list by list ID.

Delete a list by its ID.

List the digest instances for a schedule. Each instance represents the events accumulated for a single user against the schedule, useful for monitoring accumulation before a digest is released.

Generate a JWT authentication token for a user. Used for client-side SDK auth (Inbox, Preferences, etc.).

Get a list by its ID.

List journey templates in the workspace, returning the journey IDs and version state of each. Optionally filter by version (published or draft).

Get all lists. Optionally filter by pattern (e.g. 'example.list.*').

Create a new user profile or merge supplied values into an existing profile (POST). Existing fields not included are preserved.

List messages you've previously sent. Filter by status, recipient, notification, provider, tags, or tenant.

List notification templates. Optionally filter by cursor.

Delete a user profile permanently.

List configured provider integrations for the workspace.

Release a digest schedule early — send what users have collected so far now instead of waiting for the scheduled time. A 204 is also returned when the schedule has no in-progress instances to release.

Resend a previously sent message. Loads the original send request and enqueues a brand-new send to the same recipient with the same content, producing a new messageId; the original message is unchanged. Rate limited per message (429 on rapid repeats).

Restore a previously deleted list.

List all tenants in the workspace.

Track an inbound event that can trigger automations. Requires event name, messageId (for deduplication), and properties.

Unsubscribe a user from a list.