Moosend API + MCP (2026): v3 REST, no official MCP server

Moosend exposes a single REST API-v3, at https://api.moosend.com/v3-covering subscribers, lists, segments, campaigns, reporting and transactional sends. It works, and it is visibly dated: auth is an apikey query-string parameter, response format is chosen by a .json or .xml extension on the path, and pagination uses path segments. On the agent side the verdict is blunt: as of August 2026 there is no official Moosend MCP server, and no dedicated community one either.

That shapes how you build. The API is simple enough that a plain HTTP client beats every official SDK, all nine of which are abandoned, but the developer surface has not moved in years, so treat Moosend as a marketing back end you script against, not a platform you expect to grow with you. For relay configuration, see SMTP settings.

At a glance

MCP integration in 2026

Model Context Protocol gives an AI agent typed, permissioned access to a platform without a hand-rolled wrapper, for an ESP, an assistant adding a subscriber or triggering an automation as a first-class tool call. Moosend has not shipped that surface, and neither has its parent company.

Available MCP servers

All three are third-party, none endorsed by Moosend, and none exposes the full v3 surface, you get whatever the intermediary modelled. Ranked by practicality.

Moosend API essentials

Moosend v3 is a resource-and-action API rather than a strict REST-verb API: writes are POST to a named action path such as /subscribe.json, reads are GET on a matching path. Two conventions catch out newcomers.

The format extension is load-bearing: /campaigns/create without .json is not the same route, and putting the query string before the extension produces a path Moosend does not recognise. Order is always path → .json → ?apikey=-centralise URL construction in one helper. Pagination has the same problem: {Page} and {PageSize} are positional segments, so omitting page size changes the route rather than applying a default, and no default is documented. Pass both, and stop paging when a collection returns shorter than the size you asked for.

Authentication methods

API key in the query string

There is exactly one documented method. Generate a key at More › Settings › API key and append it as ?apikey=YOUR_API_KEY. No Bearer token, no header key, no HMAC signing and no OAuth flow appears anywhere in the v3 reference, a connector that assumes header auth needs a special case for Moosend.

Keys inherit the creating role

A Moosend key is not a global credential: it carries the permissions of the role that generated it. Owner, Admin, Viewer, Manager, Designer, Admin observer or GDPR viewer, so a key made by a limited role only reaches what that role reaches. That is the closest thing to scoped keys on offer. For a read-only reporting key, create a dedicated user with a restricted role and generate the key as that user.

Sub-accounts and the SMTP credential split

Sub-accounts carry their own credentials, so generate the key while signed in as the sub-account, a parent key does not reach sub-account data. The relay is a separate system: smtp.mailendo.com authenticates with your Moosend account login, and a sub-account uses a domain-prefixed username of the form myaccount\username. Moosend issues no SMTP-only credential, see SMTP settings.

Rate limits

Moosend publishes no global requests-per-minute figure. Limits are per endpoint, enforced per API key, and the spread is wide enough that your architecture depends on which endpoints you touch.

The workaround differs per pinch point. For migration, drive everything through subscribe_many at one call per five seconds and accept that a large import runs for hours, parallel single subscribe calls just produce a stream of 429s. For reporting, the 2 calls / 60s statistics ceiling makes per-campaign polling impractical: build on /view_summary.json, cache recipient-level activity for an hour or more, and refresh on a queue rather than on page load. For transactional volume, 6 calls / 1s is about 21,600 messages an hour at perfect saturation, fine for receipts, thin for a real transactional workload, where Postmark fits better. No Retry-After header is documented, so use exponential backoff with jitter.

Official SDKs

Moosend publishes API wrappers for nine languages. All are Swagger-generated and none is maintained: eight were last committed on October 2-3, 2017, the PHP wrapper alone reaching February 2020. Read them for request shapes; do not add them to a manifest.

Only two ship through a package manager: moosend-api on npm and moosend/api-wrappers-php on Packagist. The Python wrapper was never published to PyPI, installation is git-only and its README still advertises Python 2.7.

Notable community SDKs

There is no meaningful third-party SDK ecosystem here. npm, PyPI and Packagist surface no maintained community client with real adoption, unsurprising for an API this thin, where a wrapper would be a hundred lines. The community routed around it with iPaaS connectors instead: the official Zapier app, the Make app in Moosend’s own directory, plus Pipedream, viaSocket, ApiX-Drive and Pabbly Connect. Any of those is a more realistic abstraction layer than a hand-rolled SDK, and Zapier doubles as your MCP path. The only first-party code with recent commits is the website tracking library (June 2024), a browser snippet, not an API client.

Endpoints reference

Fifteen of the most-used routes are below. Every path takes a {Format} extension of json or xml plus the apikey parameter. Request bodies and field types live in the official API documentation.

Code examples

Verify a key and list senders (curl)

Moosend has no ping endpoint. /senders/find_all.json is the cheapest read that proves a key works, and it doubles as the fastest way to confirm from code that a sending domain cleared SPF, DKIM and DMARC.

curl -s "https://api.moosend.com/v3/senders/find_all.json?apikey=YOUR_API_KEY"

# Success looks like:
# { "Code": 0, "Error": null, "Context": { "Senders": [ ... ] } }
#
# A bad key still returns HTTP 200. Check Error, not the status code.

Add a subscriber (Python)

import requests

API_KEY = "YOUR_API_KEY"
LIST_ID = "YOUR_MAILING_LIST_ID"
BASE = "https://api.moosend.com/v3"

# Note the .json extension and the apikey QUERY parameter - Moosend has
# no header-based auth and no Accept-header negotiation.
url = f"{BASE}/subscribers/{LIST_ID}/subscribe.json"

resp = requests.post(
    url,
    params={"apikey": API_KEY},
    json={
        "Name": "Ada Lovelace",
        "Email": "ada@example.com",
        "CustomFields": ["Country=Greece", "Plan=Pro"],
    },
    timeout=30,
)

# {"Code": 429, "Error": "RATE-LIMITING"} - subscribe is capped at 10 calls / 10s
if resp.status_code == 429:
    raise SystemExit("Rate limited by Moosend, back off and retry")

data = resp.json()

# Moosend returns HTTP 200 even for logical failures: always check Error.
if data.get("Error"):
    raise SystemExit(f"Moosend error: {data['Error']}")

print(data["Context"])

Custom fields are an array of Name=Value strings rather than an object, and each must already exist on the list, posting an unknown field name returns HTTP 200 with a populated Error.

Add a subscriber (Node)

// The official 'moosend-api' package is untouched since 2017 - use fetch.
const { MOOSEND_API_KEY: KEY, MOOSEND_LIST_ID: LIST } = process.env;

async function subscribe(email, name) {
  const url = `https://api.moosend.com/v3/subscribers/${LIST}`
            + `/subscribe.json?apikey=${KEY}`;

  const res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ Name: name, Email: email,
      CustomFields: ["Country=Greece", "Plan=Pro"] }),
  });

  if (res.status === 429) throw new Error("RATE-LIMITING: 10 calls / 10s");

  // Every response is { Code, Error, Context } with HTTP 200 even on
  // failure - never trust the status code alone.
  const data = await res.json();
  if (data.Error) throw new Error(`Moosend error: ${data.Error}`);
  return data.Context;
}

Common gotchas

Deprecations and changelog

Moosend’s official release notes have been silent since early 2023, so the two most consequential recent changes, an ownership transfer and an SMTP port retirement, were announced elsewhere. The record below stitches those sources together.

• October 1, 2025-SMTP ports 465 and 25000 retired; port 587 with STARTTLS becomes the only supported submission path. Automations and API campaigns were unaffected.
• June 6, 2025-Constant Contact announces its acquisition of Moosend from Sitecore. Moosend continues as a standalone brand and keeps powering Sitecore Send. Any source still calling Moosend “Sitecore-owned” is out of date.
• February 1, 2023-Sitecore Content Hub DAM integration ships. This is the final entry on the official “What’s new in Moosend” page.
• December 1, 2022-Moosend migrates its API documentation to a tri-pane layout with outline, content and code samples side by side. The last developer-facing change on record.
• May 3, 2021-Sitecore completes its acquisition of Moosend, later white-labelling the platform as Sitecore Send.

No API version has been deprecated: v3 is the only documented version and no v4 is announced. The real risk is stagnation, not a version cut. Check the official release notes before assuming anything here has changed, and read the absence of entries as data.

Frequently asked questions