Email marketing platform
Campaign Monitor logo

Campaign Monitor API + MCP (2026): v3.3, 7 SDKs, no MCP server

Campaign Monitor exposes one public REST API — v3.3 at https://api.createsend.com/api/v3.3/ — covering campaigns, clients, lists, subscribers, segments, journeys, templates, webhooks and transactional email. Seven client libraries sit in the official GitHub organisation; only two saw a commit in 2026. On the agent axis the verdict is blunt: as of August 2026 there is no official Campaign Monitor or Marigold MCP server. Every agent pipeline in production runs on a community wrapper, a broker, or bespoke glue over v3.3.

At a glance

v3.3
Current REST API version
JSON only · v3.1 paths still resolve
7
Official client libraries
Only Ruby and Java touched in 2026
0
Official MCP servers
3 unofficial routes only

MCP integration in 2026

Model Context Protocol lets an LLM agent discover and call a vendor’s API without a hand-written integration layer — list campaigns, add a subscriber, fire a transactional send, all as typed tool calls. A first-party server means the vendor owns the tool surface, the auth model and the rate-limit behaviour. Campaign Monitor has shipped nothing, so all three belong to whoever wrote your wrapper.

i

No official MCP server from Campaign Monitor or Marigold

Checked 19 August 2026 across the developer portal, the campaignmonitor GitHub organisation and the official changelog — no endpoint, no announcement, no roadmap entry. The 2026 changelog is entirely in-app AI features, none agent-facing. Peers such as Adobe Marketo Engage and MoEngage already publish first-party servers, so this is a real gap rather than an industry-wide lag.

Available MCP servers

Three routes exist, none run by Campaign Monitor. Weigh them on who holds your API key: the community server keeps it in your config, the brokers hold it on theirs.

Why buyers should care

An MCP gap is not a reason to reject Campaign Monitor, but it changes three things. Support: when a community server breaks against an API change there is no vendor SLA. Security review: a third-party wrapper holding a full-scope key rarely clears procurement, and the Campaign Monitor key is account-wide. Longevity: a 113-tool surface maintained by one person is a different bet from a vendor-owned server. If agent access is a hard requirement, budget for a thin internal wrapper over the endpoints you use. Buyers wanting a first-party agent story should compare HubSpot, Brevo and Mailchimp first.

Campaign Monitor API essentials

v3.3 is a conventional resource-oriented REST surface. Everything hangs off a client — the tenant owning lists, campaigns, journeys and transactional groups — so nearly every call needs a clientID or an ID derived from one. Responses are JSON, and errors carry a numeric Code plus a Message, not just an HTTP status.

Base URLhttps://api.createsend.com/api/v3.3/
Current versionv3.3 RECOMMENDED — legacy v3.1 paths still resolve
Response formatJSON
Resource families11 — Account, Campaigns, Clients, Journeys, Lists, Segments, Subscribers, Templates, Transactional, Webhooks
Standard paginationpage, pagesize, orderfield, orderdirection
Pagination envelopeResults, PageNumber, PageSize, RecordsOnThisPage, TotalNumberOfRecords
Transactional paginationCursor — sentBeforeID / sentAfterID, 50 default, 200 max
Recipients per send25 across To + CC + BCC combined
AttachmentsPDF only, up to 25 MB
Smart email Data field100 KB ceiling

Two pagination models coexist and confusing them is the most common integration bug. Standard collections are offset-paged: request a page and read NumberOfPages off the envelope. The transactional timeline is cursor-paged: pass the last ID you saw as sentBeforeID and walk backwards, because the collection mutates while you read it. One generic paginator will silently skip or duplicate records.

The split inside transactional shapes the whole integration. Classic means you supply the entire message — subject, From, recipients, HTML, text, attachments — and it can go over REST or the SMTP relay documented on the Campaign Monitor SMTP tab. Smart means the template lives inside Campaign Monitor and you POST only a Data object of merge variables. Smart emails are API-only.

Authentication methods

Three credential types exist and they are not interchangeable. Picking the wrong one is the largest single source of 401 responses here.

HTTP Basic with an API key

The default for server-side code you own. Take the key from Account Settings › API keys and send it as the Basic username, with any non-empty dummy string as the password — that field is ignored. The key authenticates the whole account, so one leak exposes every client, list and campaign.

OAuth 2.0

The right choice for any third-party application acting on someone else’s account. Both the Web Application and Non-Web Application flows are supported. Access tokens expire and renew via a refresh token, so you need durable token storage and a refresh path before you ship, not after the first expiry incident.

SMTP tokens

A transactional-only credential used only by the smtp.api.createsend.com relay, with the same token string in both the SMTP username and password fields. An SMTP token is not an API key and vice versa — neither authenticates against the other surface.

The API key has no scopes

There is no read-only key, no per-client key and no per-resource grant. One key unlocks every client in the account, including campaign creation and subscriber export. To give a contractor, internal tool or AI agent narrower access your only options are OAuth — revocable per application — or your own proxy whitelisting the endpoints that tool needs. This is why handing the raw key to a third-party MCP wrapper is hard to justify in a security review.

Rate limits

Campaign Monitor documents that rate limiting is enforced and how to detect it, but never publishes the ceiling. Treat the headers as the contract, not a constant in your client.

LimitValueNotes
Requests per minuteNot publishedApplies to /transactional; read headers rather than assume
Throttle responseHTTP 429Body message “Rate limit exceeded”
Throttle headersX-RateLimit-Limit, -Remaining, -ResetBack off until Reset
Recipients per message25Hard cap across To, CC and BCC combined
Attachment size25 MBPDF only — no CSV, ICS or image files
Message timeline page50 default / 200 max/transactional/messages, cursor-paginated
Smart email payload100 KBThe Data merge object

The workaround is a client that reads X-RateLimit-Remaining on every transactional response and pauses until X-RateLimit-Reset as it nears zero, rather than a fixed sleep. Because the ceiling is undocumented it can move without a changelog entry, so any value you measure locally is an observation, not a guarantee. Plan allowances bite earlier for most accounts: on the Basic monthly plan transactional counts against the tier’s combined send limit, while Unlimited and Premier allow 10x the tier’s subscriber limit. Overrunning it silently moves the account to a higher pricing tier — alert on that yourself first.

Official SDKs

Seven client libraries live in the official campaignmonitor GitHub organisation. They are thin wrappers over REST, not opinionated frameworks — good for stability, bad if you expected retries or typed models. Cadence varies sharply, so check the last-push column before standardising.

LanguagePackageInstallRepo & last push
Rubycreatesendgem install createsendcreatesend-ruby6 Jul 2026
Javacreatesend-javaMaven com.createsendcreatesend-java5 Apr 2026
Pythoncreatesendpip install createsendcreatesend-python8 Sep 2025
PerlNet::CampaignMonitorcpan Net::CampaignMonitorcreatesend-perl2 Jul 2025
PHPcampaignmonitor/createsend-phpcomposer require the packagecreatesend-php18 Jun 2025
.NET / C#createsend-dotnetInstall-Package createsend-dotnetcreatesend-dotnet12 Mar 2025
Objective-CCreateSendCreateSend CocoaPodcreatesend-objectivec7 Dec 2021

Five of seven SDKs have not moved in over a year

Only Ruby and Java received commits in 2026. PHP, .NET and Perl last moved in 2025; the Objective-C client has been dormant since December 2021. The risk is not that a stale SDK stops working — v3.3 is stable — it is that newer transactional and journey endpoints have no method in the library, and dependency CVEs go unpatched. For PHP and .NET, call REST directly.

Notable community SDKs

No third-party client rivals the official set, because the API is simple enough that teams wrap the endpoints they need in-house. The most substantial community artefact is not an SDK but cmon-mcp, whose roughly 113 generated tools are a de facto JavaScript coverage map of v3.3. For JavaScript and Go, where nothing official exists, direct HTTP calls with Basic auth are a fifteen-line helper.

Endpoints reference

These cover the two jobs developers actually integrate: sending transactional mail, and keeping subscriber data in sync. Full method-by-method reference — campaign reporting, suppression lists, custom fields, journey breakdowns — is in the official v3.3 documentation.

ResourceMethodsDescription
Classic email send
/transactional/classicEmail/send
POSTSends a self-supplied message. The only path with an SMTP equivalent.
Classic email groups
/transactional/classicEmail/groups
GETLists the group names bucketing classic sends for reporting.
Smart email list
/transactional/smartEmail
GETLists smart emails by status, optionally scoped to a clientID.
Smart email details
/transactional/smartEmail/{smartEmailID}
GETReturns one smart email’s config and the variables it expects in Data.
Smart email send
/transactional/smartEmail/{smartEmailID}/send
POSTTriggers a hosted template with a Data payload. API only, never SMTP.
Statistics
/transactional/statistics
GETDelivery and engagement metrics by group, smart email ID and date.
Message timeline
/transactional/messages
GETSent messages, cursor-paginated, 50 default and 200 max.
Message detail
/transactional/messages/{messageID}
GETOne message with status and, inside 30 days, its content.
Message resend
/transactional/messages/{messageID}/resend
POSTSent or soft-bounced messages under 30 days only. Attachments dropped.
Clients
/clients
GET, POSTLists or creates clients — the tenant owning lists, campaigns and groups.
Client detail
/clients/{clientID}
GET, PUT, DELETEReads, updates or deletes a client and exposes its lists and campaigns.
Campaigns
/campaigns/{clientID}
POSTCreates a draft campaign from list or segment IDs plus HTML.
Lists
/lists/{clientID}
POSTCreates a list. Sibling routes manage custom fields and subscriber views.
Subscribers
/subscribers/{listID}
GET, POST, PUTAdds, updates or looks up a subscriber by email. /import handles bulk.
Webhooks
/lists/{listID}/webhooks
GET, POST, DELETERegisters callbacks for Subscribe, Update, Bounce and Spam events.

Code examples

Verify an API key with cURL

The fastest credential smoke test. The key goes in the Basic username field and the password is ignored, so any placeholder works.

# API key as username, any dummy string as password
curl -s -u "$CM_API_KEY:x" https://api.createsend.com/api/v3.3/clients

# 200 + JSON -> valid; entries carry ClientID and Name
# 401        -> wrong key, revoked, or you pasted an SMTP token

Send a classic transactional email in Python

Classic means you supply the whole message. Note clientID as a query parameter, the 25-recipient ceiling, and ConsentToTrack, which is mandatory.

import os, requests

r = requests.post(
    "https://api.createsend.com/api/v3.3/transactional/classicEmail/send",
    params={"clientID": os.environ["CM_CLIENT_ID"]},
    auth=(os.environ["CM_API_KEY"], "x"),  # key as user, dummy password
    json={
        "Subject": "Your password reset link",
        "From": "Acme Support <support@mail.example.com>",  # authenticated
        "To": ["customer@example.com"],    # max 25 across To + CC + BCC
        "HTML": "<p>Reset your password.</p>",
        "Text": "Reset your password.",
        "Group": "Password resets",        # reporting bucket, not a list
        "TrackClicks": False,              # keeps raw URLs alive past 90 days
        "ConsentToTrack": "Unchanged",
    },
    timeout=30,
)
r.raise_for_status()

Trigger a smart transactional email in Node.js

Smart emails keep the template inside Campaign Monitor, so the payload is just merge variables. This path has no SMTP equivalent — build on it and a relay is off the table.

const key = process.env.CM_API_KEY;
const id  = process.env.CM_SMART_EMAIL_ID;

const res = await fetch(
  `https://api.createsend.com/api/v3.3/transactional/smartEmail/${id}/send`,
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: "Basic " + Buffer.from(`${key}:x`).toString("base64"),
    },
    body: JSON.stringify({
      To: ["customer@example.com"],
      Data: { firstName: "Alex", resetUrl: "https://example.com/reset?t=a" },
      ConsentToTrack: "Unchanged",
      AddRecipientsToList: false,   // needs true AND a list picked in-app
    }),
  }
);
if (!res.ok) throw new Error(await res.text());

Common gotchas

Smart transactional emails can never be sent over SMTP

Campaign Monitor splits transactional into two products and only classic speaks SMTP. Build your notifications around Campaign Monitor-hosted templates — the whole selling point of smart emails — and you are locked into POST /transactional/smartEmail/{id}/send. Decide which model you need before plumbing an SMTP client into your app: moving between them rewrites the send path.

Three credential types, none interchangeable

REST takes an API key as the Basic username with a dummy password. The relay takes an SMTP token as both username and password. OAuth works on REST only. Pasting an API key into an SMTP client, or an SMTP token into an Authorization header, fails with no hint about which family was wrong. Name the variables distinctly (CM_API_KEY versus CM_SMTP_TOKEN).

Transactional requires a monthly plan plus verified authentication

Two prerequisites are documented and both fail silently. The account needs the transactional permission, and per the official billing article you must use email authentication and be on a monthly plan. Pay-as-you-go credit accounts cannot send transactional email at all, with no upgrade path short of changing billing model. Accounts without the cm._domainkey DKIM record and the _spf.createsend.com SPF include are blocked too, so DNS work is a precondition, not a deliverability nicety.

25 recipients, PDF-only attachments, and resends drop the attachment

25 recipients maximum across To, CC and BCC combined, so larger fan-out must be chunked client-side. Attachments are PDF only, up to 25 MB — no CSV export, no ICS invite, no PNG receipt, which rules out many standard use cases. Over SMTP there is an extra constraint the API lacks: attachment filenames must use standard Latin characters only. And resent messages that originally carried attachments go out without them — the recipient gets a mail referencing a document that is not there.

Content lives 30 days, logs 90 days, tracked links die at 90 days

Retention is short and asymmetric. Content is stored 30 days for previewing and resending; log, open and click data are kept 90 days; and tracked links inside sent emails stop resolving after 90 days. That last one is dangerous — a customer opening a click-tracked receipt four months later hits a dead redirect. For long-lived mail such as invoices, set TrackClicks to false over the API or X-Cmail-TrackClicks: false over SMTP. Resend eligibility is narrow too: sent messages and soft bounces under 30 days only, never queued messages or hard bounces.

Deprecations and changelog

The public changelog is product-led, not API-led: the 2026 entries are in-app features, and the last documented change to the public REST surface predates them by two years. Read that as stability for existing integrations and stagnation for anyone waiting on new capability.

  • July 1, 2026 — Drip Campaigns launched, alongside My Dashboard, a customisable performance view for administrators.
  • March 1, 2026 — Website Builder AI-Generated Templates released, a month after the Website Builder launched as a $10/month add-on.
  • January 1, 2026 — AI Email Booster and Segment Mapper launched. Both are in-app AI; neither is agent-facing.
  • May 1, 2024 — “New APIs now available”, an expansion of the public v3.x REST surface. Still the most recent documented API-level change.
  • March 1, 2024 — Default sending domain activated across accounts for Google and Yahoo bulk sender compliance, with v=DMARC1; p=none; as the minimal compliant record.

No endpoint deprecations have been announced for v3.3. The v3.1 paths in older help-centre samples still resolve, but new integrations should target v3.3. Track changes on the official What’s New page.

Frequently asked questions

What is the Campaign Monitor API base URL and current version?

The current public REST API is v3.3, served from https://api.createsend.com/api/v3.3/, JSON only. Older v3.1 paths still resolve — help-centre transactional samples cite them — but target v3.3 for new work. Reference: campaignmonitor.com/api/v3-3/.

How do I authenticate: API key or OAuth?

Use an API key for server-side code on your own account: send it as the Basic username with any dummy password. Use OAuth 2.0 when your app acts on someone else’s account — both the Web Application and Non-Web Application flows are supported, with refresh tokens. The third credential, an SMTP token, exists only for the smtp.api.createsend.com relay and goes in both the username and password fields. None works on the other surfaces.

What are the Campaign Monitor API rate limits?

Rate limiting applies to /transactional endpoints and returns HTTP 429, but Campaign Monitor publishes no numeric ceiling. Responses carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset — read those at runtime and back off until Reset instead of hard-coding a rate. Documented hard limits do exist: 25 recipients per send, PDF attachments to 25 MB, a 100 KB smart email Data payload, and 200 results per timeline page.

How do I send a transactional email through the API?

Two endpoints, depending on where the template lives. POST /transactional/classicEmail/send takes the complete message from you and is the only path that also works over SMTP. POST /transactional/smartEmail/{id}/send triggers a template stored in Campaign Monitor with a Data object; API-only. Both require ConsentToTrack and cap at 25 recipients. The account needs the transactional permission, verified authentication, and a monthly (not credit-based) plan.

Which official Campaign Monitor SDKs are still maintained?

Seven exist, maintenance is uneven. Ruby (6 July 2026) and Java (5 April 2026) are actively maintained. Python (Sept 2025), Perl (July 2025), PHP (June 2025) and .NET (March 2025) work but move slowly. Objective-C has been dormant since December 2021. There is no official JavaScript, TypeScript or Go client; for those, call REST directly.

Is there an official Campaign Monitor MCP server?

No. As of August 2026 neither Campaign Monitor nor Marigold publishes one — nothing on the developer portal, in the campaignmonitor GitHub organisation, or in the changelog. Three unofficial routes exist: the Node server cmon-mcp, wrapping v3.3 in roughly 113 tools with your key held locally; hosted Pipedream MCP; and Zapier’s MCP endpoint. Because the API key is account-wide with no scopes, handing it to a third party is a real security decision; many teams build a thin internal proxy instead.

Changelog (recent)

  • 2026-08-19 API + MCP tab published. Verified that no official Campaign Monitor or Marigold MCP server exists — developer portal, campaignmonitor GitHub organisation and official changelog all checked.
  • 2026-07-06 createsend-ruby, the most actively maintained official client library, received its latest push — the only official SDK updated in the second half of 2026.
  • 2026-07-01 Drip Campaigns launched alongside My Dashboard for the administrator experience (official What's New, July 2026). Both in-app features, neither agent-facing.
AAlaa Touil RRabeb How we test →

This review follows our email infrastructure testing methodology. We disclose affiliate relationships in our editorial independence policy.