Send transactional and bulk email with MailerSend, and manage templates, domains, sender identities, suppressions, webhooks, activity and analytics.
MailerSend ships in the w6w first-party pack. It declares 43 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.mailersendMailerSend is a transactional email service, and this app covers the whole sending loop a workflow needs: send a single email or up to 500 in one bulk request, optionally scheduled up to 72 hours ahead, with templates, per-recipient personalization, tags and attachments.
Around the send it covers what keeps mail deliverable: creating and verifying sending domains and reading the DNS records they need, sender identities for addresses without a verified domain, and the suppression lists (blocklist, hard bounces, spam complaints, unsubscribes, on-hold) that decide who is never mailed. After the send, it reads the individual emails, their delivery activity and the aggregate analytics, so a workflow can act on a bounce or an open, and it manages webhooks for reacting to those events as they happen.
MailerSend tokens are scoped per area, so a connection works with exactly the permissions it was given; an action that needs a scope the token lacks says so instead of failing opaquely. Health checks track MailerSend’s own status page, live API reachability and the remaining daily request quota.
Three routes to the same 43 actions. The Workflow tab is generated from MailerSend's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
add-suppressions Add recipients to a suppression list (POST /v1/suppressions/{type}). Mail to them is then suppressed. `domainId` is required for hard bounces, spam complaints and unsubscribes; the blocklist also accepts regex `patterns` and works account-wide without one. The on-hold list cannot be added to.
create-domain Add a sending domain (POST /v1/domains). It starts unverified: publish the records from Get Domain DNS Records, then call Verify Domain.
create-sender-identity Add a sender identity (POST /v1/identities): MailerSend emails the address a verification link, and the identity can send once it is clicked. Use Resend Sender Identity Verification to send the link again.
create-template Create an email template (POST /v1/templates). `text` is required by the API unless `autoGenerate` is true, in which case it is built from the HTML. Templates created here can later be edited with Update Template; templates built in the MailerSend app cannot.
create-webhook Create a webhook on a domain (POST /v1/webhooks). MailerSend sends a `webhook.test` ping to the URL first and only saves the webhook if it answers 2xx. The signing secret MailerSend generates is stripped from the result: this app never returns it.
delete-domain Permanently delete a sending domain (DELETE /v1/domains/{id}). Sending from it stops immediately.
delete-recipient Delete a recipient record and its domain association (DELETE /v1/recipients/{id}), for example to honour an erasure request.
delete-scheduled-message Cancel a scheduled email before it is sent (DELETE /v1/message-schedules/{id}).
delete-sender-identity Delete a sender identity (DELETE /v1/identities/{id}).
delete-suppressions Remove entries from a suppression list so mail to them flows again (DELETE /v1/suppressions/{type}). Pass the entry `ids` from List Suppressions, or set `all` to empty the list. `all` is destructive: the vendor offers no undo.
delete-template Delete a template (DELETE /v1/templates/{id}). A scheduled email that uses it is not sent once the template is gone.
get-activity Read one activity event with its email and recipient (GET /v1/activities/{id}). Note the plural `activities` in the path, where the list is `activity`.
get-analytics-by-date Event counts over time (GET /v1/analytics/date), bucketed by day, week, month or year. Every date in the range is present, including those with no events, and every requested event appears with a count (0 by default).
get-bulk-email-status Read a bulk send's progress (GET /v1/bulk-email/{id}): `state`, recipient counts, `validation_errors` (indexed `message.{n}` in send order) and `suppressed_recipients`.
get-domain Read one sending domain, including its settings and verification flags (GET /v1/domains/{id}).
get-domain-dns-records Read the DNS records a domain needs (GET /v1/domains/{id}/dns-records): `spf`, `dkim_ms1` and `dkim_ms2` (DKIM is two CNAMEs now), `return_path`, `custom_tracking` and `inbound_routing`, each with `hostname`, `type` and `value`.
get-email Read one sent email with its recipient and activity events (GET /v1/email/{id}). `text` and `html` are null when content tracking is off for the domain. Needs an `email_full`, `activity_read` or `activity_full` token.
get-message Read one message with its domain and the emails it created (GET /v1/messages/{id}). `emails` stays empty until the send has been processed.
get-opens-analytics Opens grouped by country, user-agent name or user-agent type (GET /v1/analytics/{country|ua-name|ua-type}). `data.stats` is a list of `{ name, count }`; for country, `name` is a two-letter code and is absent when there is no data.
get-scheduled-message Read one scheduled message (GET /v1/message-schedules/{id}): `send_at`, `status`, `status_message`, its domain and message.
get-template Read one template with its category, domain and stats (GET /v1/templates/{id}).
get-webhook Read one webhook (GET /v1/webhooks/{id}). Any signing-secret field is stripped from the result.
list-activities List a domain's delivery events (GET /v1/activity/{domainId}): sent, delivered, bounced, opened, clicked, suppressed and so on. `dateFrom` and `dateTo` are required and the window is capped by your plan's retention (1 to 30 days). `deferred` and `suppressed` need a Starter plan. 10 requests/minute, shared with List Emails.
list-domains List sending domains with their verification flags (`is_verified`, `spf`, `dkim`, `tracking`) and `domain_settings` (GET /v1/domains).
list-emails List the individual emails a domain sent in a window (GET /v1/emails), newest first, with status, interaction and suppression reason. `domainId`, `dateFrom` and `dateTo` are required. Walk pages by following `links.next` until it is null: there is no `total` or `last_page`. Shares a 10 requests/minute budget with List Activities.
list-messages List messages (one per send request) (GET /v1/messages). A message holds the emails it produced; use List Emails to see delivery state.
list-recipients List the addresses MailerSend has sent to (GET /v1/recipients). These are records of past sends, not a mailing list.
list-scheduled-messages List emails queued with `sendAt` (GET /v1/message-schedules), with `send_at`, `status` and `status_message`.
list-sender-identities List sender identities, the verified from-addresses that work without verifying a whole domain (GET /v1/identities).
list-suppressions List the recipients on one suppression list (GET /v1/suppressions/{type}): blocklist, hard bounces, spam complaints, unsubscribes or on hold. Each row's `id` is what Delete Suppressions takes. The default page size here is 10 (the vendor's own).
list-templates List email templates (GET /v1/templates). Use a template's `id` as `templateId` in Send Email.
list-webhooks List a domain's webhooks (GET /v1/webhooks). `domain_id` is required by the API. Any signing-secret field is stripped from the result.
resend-sender-identity-verification Send the verification email for a sender identity again (POST /v1/identities/{id}/resend).
send-bulk-email Send up to 500 independent emails in one request (POST /v1/bulk-email). Validation and suppression errors are not returned here: they are stored against the returned `bulkEmailId`, so follow up with Get Bulk Email Status. Needs a Hobby plan or higher; limited to 10 requests a minute.
send-email Send one transactional email (POST /v1/email). The call is asynchronous: a 202 means queued, and the `x-message-id` header is returned as `messageId`. Provide `html`, `text` or `templateId`. When every recipient is suppressed nothing is sent and `messageId` is null.
update-domain-settings Change a domain's sending and tracking settings (PUT /v1/domains/{id}/settings). Only the fields you set are sent. `sendPaused: true` stops all sending from the domain.
update-sender-identity Change a sender identity's name or reply-to (PUT /v1/identities/{id}). The address itself cannot be changed.
update-template Update a template (PUT /v1/templates/{id}); only the fields you set are sent. Only templates created through the API can be updated: one built in the MailerSend app answers 404.
update-webhook Change a webhook (PUT /v1/webhooks/{id}); only the fields you set are sent. Changing the URL triggers the same `webhook.test` ping as creation. Pass `enabled: false` to pause deliveries.
verify-domain Ask MailerSend to re-check a domain's DNS (GET /v1/domains/{id}/verify). Answers 200 either way: read `data` (`dkim`, `spf`, `mx`, `tracking`, `cname`, `rp_cname`) and `message`, not the status, to learn whether it passed.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying MailerSend's real ids.
{
"manifestVersion": "2",
"name": "mailersend-example",
"steps": [
{
"id": "add-suppressions",
"uses": {
"app": "io.w6w.mailersend",
"action": "add-suppressions",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"type": "<type>"
}
}
]
}add-suppressions create-domain create-sender-identity create-template create-webhook +38 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for MailerSend, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to MailerSend. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "add-suppressions",
payload: {
type: "<value>",
// domainId: "<value>",
// recipients: "<value>",
// patterns: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action add-suppressions --payload '{"type":"<value>"}' Give an AI agent MailerSend — without giving it MailerSend's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.mailersend#add-suppressions",
"input": {
"type": "<type>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's MailerSend connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
MailerSend's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. MailerSend itself is MIT, and the runtime that executes it is source-available (FSL).
MailerSend declares its own checks, so its health is a property of the app rather than something the host guesses at.
From status.mailersend.com (incident.io, Statuspage v2 shape). The worst of `Email sending API`, `Bulk endpoint` and `MailerSend APP` decides; the other components are shown as detail.
An unauthenticated GET /v1/domains. The documented JSON 401 (`{ message }`) proves api.mailersend.com is serving; it says nothing about any credential.
Requests left in today's quota (`x-apiquota-remaining`, resets at midnight UTC) and in the current minute (`x-ratelimit-remaining`), from a signed GET /v1/domains. The probe spends one request.