Key takeaway
An email marketing API is the programmatic interface to the campaign side of a platform: contacts, lists, segments, templates, campaigns, flows, suppression, events, sending domains. On most platforms that half is a separate product with its own pricing ladder and a thinner API than the transactional one. I run those nine objects down a vendor's docs before integrating, and the one that catches teams is the 200 that means accepted, not delivered.
What an email marketing API actually is.
An email marketing API is the programmatic interface to the campaign side of an email platform. Audiences, templates, campaigns, and the results that come back, all addressed by code instead of by a person in a dashboard. On most platforms it's the smaller, later, and thinner half of the product, because the campaign side was built for somebody clicking and the API arrived afterwards. I've watched teams wire up a send endpoint in an afternoon and then discover there's no way to create the audience they meant to send to. The send was never the hard part.
"Marketing" is doing real work in that sentence. A transactional send is one message to one person, triggered by something that happened: a receipt, a password reset, a shipping notice. A marketing send is one message to a defined audience, on a schedule or on a trigger that fires across a list, and it carries an unsubscribe obligation the receipt doesn't. Different unit, different objects. A transactional API needs a recipient, a payload, and a verified sending domain. A marketing API needs somewhere to keep the audience, a rule that decides who's in it, a template with variables in it, and a record of what came back.
The rest of this page is the check I'd run before integrating one: whether the platform is selling you one product or two, which objects the API exposes, how a campaign send is sequenced, what doesn't change just because code pressed send, and where the same split is now landing on the agent surface.
Marketing and transactional are usually two products.
On most platforms these aren't two endpoints on one API. They're two products, with two pricing ladders, two sets of docs, and sometimes two accounts. A developer integrating the send endpoint rarely finds that out from the documentation, because the documentation for each half reads like a whole platform. It's on the pricing page.
Four platforms, four versions of the same split:
- Elastic Email: marketing and the API are separate products, and the pricing pages tell a customer on one to create a new account to try the other.
- SendGrid: Email API and Marketing Campaigns are sold as two separate products, each priced on its own Twilio page.
- Resend: transactional bills on emails sent and marketing bills on contacts stored, so an account that starts using Broadcasts adds a second plan on top of the first.
- HubSpot: marketing email has its own API, separate from the Engagements API that carries sales email.
The consequence for a buyer is that the price you were quoted and the API you were shown may not be the same purchase, and which is which is answered on the pricing page rather than in the reference. Read both ladders before you integrate either one. This is what it looks like when the campaign side was never designed to be driven by anything but a person: the transactional half got an API because a machine was always going to call it, and the marketing half got a dashboard because a marketer was always going to sit in front of it. I've watched the fix for that split go wrong in the other direction too: a bulk outreach job wired onto the transactional path because it was the one endpoint already built. That's a deliverability and compliance trap, not a shortcut.
What a marketing API has to expose.
A use-case list tells you what somebody else did with an API. The check that survives contact with a vendor's docs is narrower, and it's a list of objects rather than outcomes: are these nine things addressable? That's the difference between an API you can send with and an API you can run a programme with.
- Contacts: create, read, and update people and their custom fields.
- Lists: group contacts statically, by membership rather than by rule.
- Segments: define a rule that keeps a group current and resolves at send time.
- Templates: store and render the content, with variables the send fills in.
- Campaigns: create the send itself, schedule it, and address it to an audience.
- Flows: multi-step automation with triggers, waits, and branches.
- Suppression: the do-not-send list, readable as well as writable.
- Events: what came back, by contact and by send.
- Sending domains: add a domain and verify its DKIM and DNS records.
Most platforms answer yes to the first four and go quiet somewhere around campaigns and flows. HubSpot's marketing email API is the clean illustration: it documents create and retrieve, and the /publish and /unpublish endpoints need Marketing Hub Enterprise or the transactional email add-on. So the API can compose a campaign and can't send it without the top tier. That isn't an oversight, it's the shape of a product where publishing was a button somebody pressed. Run the nine down any vendor's reference and you'll know inside ten minutes whether you're buying a send endpoint or a platform. We answer all nine on one API, on the sending side: Nitrosend doesn't receive or parse inbound mail, so an integration that also needs to read a mailbox needs something else for that half.
How a campaign send works through an API.
A campaign send is five calls rather than one, and they go in this order.
- Create or select the audience, either a list or a segment whose rule resolves at send time.
- Create or reference the template, with the variables the campaign will fill.
- Create the campaign, binding that template to that audience.
- Schedule it or send it, and get an identifier back rather than a delivered message.
- Read the results back as events, against contacts and against the send.
That sequence is also the honest answer to "should I use SMTP or an API", which is the wrong question for campaign sending. SMTP is a protocol for handing one message to a server. It knows a sender, a recipient, and a payload, and it knows nothing about audiences: there's no SMTP verb for "the people who opened the last three sends". An API is how you address the objects above, and SMTP is how a single message moves once something else has decided who it's for.
Step four is where most first integrations go wrong. A campaign is a job, not a request. The call returns an identifier because the platform has accepted the work, not because anybody received anything, and code that reads a 200 as a delivery will report a clean send for a campaign that bounced in full.
The rules don't relax because a machine pressed send.
Bulk email carries obligations that are written down, and none of them have an exemption for code. One-click unsubscribe is the clearest case, because it's a specification rather than a courtesy. RFC 8058 defines it: a List-Unsubscribe-Post header carrying the single key-value pair List-Unsubscribe=One-Click, sent alongside a List-Unsubscribe header, with both covered by a valid DKIM signature. A link in the footer isn't that. A mailbox client can't press a footer.
The mailbox provider states the threshold. Google's requirements for bulk senders reach anyone sending more than 5,000 messages a day to Gmail accounts: SPF and DKIM on the sending domain, DMARC, spam rates in Postmaster Tools kept below 0.30%, and one-click unsubscribe on marketing and subscribed messages, with a visible unsubscribe link in the body as well.
A dashboard makes most of it unavoidable. The unsubscribe link is already in the template the tool handed you, the suppression list is applied before the send leaves, and the authentication check runs before the button lights up. Code makes every one of those optional. An API that will send to an audience without reading suppression first isn't a faster dashboard, it's a way to file the same mistake at machine speed, ten thousand times, in the seconds before anybody notices.
That's why suppression sits on the checklist above, and why it has to be readable and not only writable. Writable suppression means the platform can record an unsubscribe. Readable suppression means your code can ask, before it builds the audience, who it isn't allowed to contact. Any integration that sends campaigns needs the second one, and plenty of marketing APIs document only the first.
The same split is now repeating at the agent layer.
The live version of this question is no longer whether a platform has an API. It's whether an agent can reach the campaign objects through one. MCP servers are how that access is being packaged, and they're being built vendor by vendor, at different scopes.
Mailchimp's official MCP server covers Mailchimp Transactional, formerly Mandrill, and exposes nine tools that mirror what the Transactional API already does. There's no official MCP for the Marketing API, which is the half with audiences and campaigns on it. It authenticates with a static bearer key in the header rather than OAuth, so an agent connection carries the account's identity and no per-user identity at all.
Resend went the other way, and it's worth saying plainly: its MCP server covers the whole platform, with broadcasts, automations, segments, and domains included, so an agent there can build and send a campaign rather than only push a message. The useful point isn't that one vendor moved faster. It's that the nine-object question repeats one layer up, and you'll be asking it again, per vendor, about the agent surface.
There's a structural reason it keeps landing this way. An agent surface added to a dashboard-first product inherits whatever the API already exposed, and where the API was the transactional half, the transactional half is what the agent gets. Nothing about the retrofit fixes the gap underneath it. We built in the other order: every capability is an API endpoint and an MCP tool before it's a screen, so there's no second half waiting to catch up. That settles what's addressable here and nothing about anybody else's agent surface, which is why the nine objects stay a question to re-ask per vendor rather than one to file as answered.
Run the campaign side from the same place you send.
If you've run the nine-object checklist and found your platform answers it in two halves, on two ladders, with an agent surface over one of them, that's the problem Nitrosend is built around. Contacts, lists, segments, templates, campaigns, flows, suppression, events, and sending domains sit on one API and one MCP surface, so the audience side is addressable by the same thing that sends. Start on the free tier, unlimited contacts included, and run the checklist against us.
Sources
- Elastic Email, Email API pricing: marketing and the API sold as separate products, and the statement that a customer on one has to open a new account to use the other.
- Twilio SendGrid: Email API and Marketing Campaigns priced on two separate pages.
- Resend, how pricing works: transactional priced on emails sent and marketing priced on contacts stored, so the two halves are two plans.
- HubSpot, Marketing Emails API: create and retrieve operations, publish and unpublish gated to Marketing Hub Enterprise or the transactional email add-on, and sales email on a separate API.
- RFC 8058: Signaling One-Click Functionality for List Email Headers, the header pair behind one-click unsubscribe and the DKIM signature it has to carry.
- Google, email sender guidelines: the 5,000 messages a day threshold, SPF, DKIM, DMARC, the 0.30% spam-rate limit, and one-click unsubscribe on marketing mail.
- Mailchimp, Transactional MCP guide: the nine tools that mirror the Transactional API, and the static bearer key an agent connection authenticates with.
- Resend, MCP server: platform-wide coverage including broadcasts, automations, segments, and domains.
Common questions
It's the programmatic interface to an email platform: a way for your code to create contacts, build segments, store templates, create and schedule campaigns, and read the results back, instead of a person doing each of those in a dashboard. On a marketing platform specifically, it covers the campaign side rather than single triggered messages.
It depends which half you're buying. Vendors commonly price the transactional API on emails sent and the marketing side on contacts stored, so the two are often two bills on two ladders. Before you compare headline prices, check whether the number you were quoted covers campaigns and audiences or only sending.
Yes, commonly, either as a capped free tier or as a time-limited trial. The cap usually sits in a different place on each half: contacts on the marketing side, monthly or daily sends on the transactional side. Nitrosend's free plan includes unlimited contacts, and so does every plan above it.
SMTP is a delivery protocol: hand it a sender, a recipient, and a message, and it moves that one message and nothing else. Audiences aren't in its vocabulary, so it can't be asked who should receive something. An API addresses the objects a campaign is made of: contacts, lists, segments, templates, and the campaign itself. For campaign sending, that's the whole difference.
On many platforms, no. They're two products with two pricing ladders, and with some vendors two accounts. Check three things on the pricing page before you integrate: whether both halves sit on one plan, whether contacts and suppression are shared between them, and whether one API key reaches both.
You read events back, against the contact and against the send. Delivery, bounce, open, click, and unsubscribe are the usual set, and platforms expose them by polling an events resource, by exporting a report, or by pushing to a handler you host. Check which of the three your vendor offers before you build reporting.
Yes, and it isn't a template convention. RFC 8058 defines a header pair: <code>List-Unsubscribe-Post</code> carrying <code>List-Unsubscribe=One-Click</code>, alongside <code>List-Unsubscribe</code>, both covered by a valid DKIM signature. Google asks bulk senders for it on marketing mail, with a visible unsubscribe link in the body too. Sending by API changes none of that.
Only if the campaign objects are exposed to the agent surface. Some official MCP servers cover a whole platform, broadcasts, automations, and segments included; others mirror the transactional API only, which lets an agent send a message but not build an audience. Check what the server exposes, not whether one exists.