--- title: "Mailercloud Integration" description: "Mailercloud puts email marketing, a transactional Email API, and an email verifier behind one connection. Agents manage campaigns, contacts, lists, segments, and automations, send transactional and mail merge email, test inbox placement, and verify addresses." url: https://flowrunner.ai/integrations/mailercloud date_modified: 2026-09-04T14:28:58-07:00 --- # Mailercloud [Email Marketing](https://flowrunner.ai/integrations/category/email-marketing) Mailercloud puts email marketing, a transactional Email API, and an email verifier behind one connection. Agents manage campaigns, contacts, lists, segments, and automations, send transactional and mail merge email, test inbox placement, and verify addresses. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 64 actions · API key · available [Mailercloud website](https://cloudapi.mailercloud.com/) · [Platform Documentation](https://apidoc.mailercloud.com/) · Capability data verified 2026-08-19 1. The weekly newsletter run starts from the content system 2. Agent pulls the approved articles and renders them into the campaign body 3. Create Campaign saves the campaign as a draft, with the publish flag deliberately off 4. Get Account Details reports the remaining contact quota against the resolved audience 5. Send Campaign Test Email delivers a proof to the saved review group 6. The proof, the audience count, and the pause rule settings go to the campaign owner 7. The owner approves the send before Schedule Campaign is called ## What This Integration Enables Mailercloud is three products sharing a login, and the argument for it is that most teams already run all three and pay three bills for the privilege. There is a marketing platform with campaigns, contacts, segments, templates, and automations. There is an Email API for transactional and mail merge sending. And there is an email verifier with real-time and bulk address checking. Buying them separately means three integrations, three sets of credentials, and a reconciliation problem every time you want to know whether the address you just verified is the same one your transactional mail is bouncing off. FlowRunner agents work the whole surface through one connection. They keep contacts and their custom properties in step with the systems of record, build and proof campaigns from content that lives elsewhere, send transactional mail with per recipient substitution, and verify addresses inline or in bulk. The connector absorbs the platform's own quirks so a flow never has to know them: custom field values are keyed by property ID rather than by name, and passing a name instead stores nothing at all without raising anything; listings arrive in inconsistent shapes and are normalized to a plain array; the batch import returns a tally rather than a confirmation and the connector flags whether anything was dropped. And where an omitted field would be the difference between a draft and a send, a [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) step holds the decision. ### Without FlowRunner **Three vendors, three reconciliations**: The audience, the transactional stream, and the hygiene check each live somewhere different **Campaign drafts assembled by copy and paste**: Content is moved out of the CMS by hand every week and the formatting is redone every week **Verification treated as an occasional project**: Lists get cleaned when someone notices the bounce rate, which is after the reputation damage ### With FlowRunner **One connection across all three**: Marketing, the Email API, and the verifier are reachable from the same flow with the same credentials configured once **Drafts built by the flow, sent by a person**: The agent renders and proofs the campaign, and the send stays a decision someone makes **Hygiene runs on the same schedule as the send**: Verification is a step in the campaign flow rather than a project someone schedules separately ## Use Case Scenarios ### The newsletter that assembles itself and waits Approved posts in [WordPress](https://flowrunner.ai/integrations/wordpress) carry a publish-to-newsletter flag. Once a week the agent collects them, renders the campaign body from the saved template, and calls Create Campaign with the publish flag off so it lands as a draft. It resolves the audience from a segment, reads Get Account Details for the remaining contact quota, and sends a proof through Send Campaign Test Email to the saved review group. The rendered proof and the audience count go to the campaign owner in [Slack](https://flowrunner.ai/integrations/slack). Everything up to the moment of sending is finished; the send itself is a decision, not a step. ### Signup, verification, and transactional mail in one pass A trial signup posts an address. The agent calls Verify Emails, which uses the separate verifier key and returns a verdict, a delivery score, and the individual checks. A disposable or invalid verdict is refused at the door with a message. A clean verdict goes two places at once: Create Or Update Contact writes it to the onboarding list, and Send Email delivers the activation message through the Email API from a verified sender. The same flow that qualified the address is the one that mailed it, so there is no window where a bad address is in the list and already receiving mail. ### Bulk hygiene before a re-engagement push Before a dormant segment gets mailed, the agent calls Upload Verification File with the addresses and polls Get Verification File Status until the job reports itself finished. Download Verification Results writes the finished file into FlowRunner file storage and returns a URL the rest of the flow can read. The deliverable addresses are kept in the segment; the invalid ones are moved to a suppressed contact type with Update Contact rather than deleted, so the record survives and the address stops receiving mail. A summary lands in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) with the counts by verdict. ## Human-in-Loop Highlight In Mailercloud, an omitted field is a send. Create Campaign with the publish flag on and no scheduled time sends immediately. Schedule Campaign has the sharper edge: leaving its scheduled time empty does not park the campaign for later, it schedules it for the current moment, which sends it. And once a campaign is sending, the audience is frozen: the lists, the segments, the pause rules, and the send rules will not accept changes, and the schedule can only be edited after the campaign has been paused. The last moment when anything can be changed is the moment before that call. So the agent never fills in the publish flag. It builds the draft, proofs it, resolves the audience, and posts: "Newsletter draft ready. Audience resolves to 41,860 contacts from the Active Subscribers segment, minus 2,140 excluded by the Recent Buyers tag. Contact quota shows 12,000 remaining headroom. Pause rules set to send the first 10 percent and continue only if the open rate clears 18 percent after two hours. Proof is in your inbox. Schedule for Thursday 09:00, send now, or hold?" The owner answers. The agent then calls Schedule Campaign with the time written out in full, never left blank. Rendering forty-two thousand personalized messages is exactly what an agent should do. Deciding that they go is not. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 64 actions ### Contacts 8 - **Create Contact** Adds a contact to a list, since a Mailercloud contact always belongs to one. Custom field values are keyed by property ID rather than name. An address that already exists is reported rather than duplicated. Used at the front of signup and import flows where the address is expected to be new. - **Create Or Update Contact** Creates the contact, or updates the existing one when the address is already present, and reports which happened. This is the safe choice for a signup path where the same person may return. - **Update Contact** Updates a contact by ID or address. The list membership and the address itself cannot be changed here, so moving a contact between lists means adding it to the other one. Used to write behavior back onto the record and to change contact type. - **Get Contact** Reads one contact with its stored fields, custom property values, and tags. Used before any conditional write, and for support lookups. - **Delete Contact** Permanently deletes a contact. Deleting does not suppress the address: to stop mailing while keeping the record, set the contact type instead. Used for erasure requests and genuine data errors. - **Create Contacts In Batch** Adds up to fifty contacts to one list in a single call and answers with submitted, inserted, updated, and skipped counts. A contact can be skipped without any error being raised, so the connector adds a flag saying whether everything landed. Used for periodic synchronization from a system of record. - **List Contacts In List** Returns a page of the contacts on one list with their stored fields. Used for reconciliation and export. - **Remove Contact Tags** Removes tags from a contact, by ID or by name. An unknown tag fails the whole call rather than partially applying, which makes the operation safe to retry. Used for lifecycle stage maintenance. ### Custom Properties 4 - **List Properties** Lists the account's custom contact properties with their IDs. Run first by any flow that writes custom field values, because the write is keyed on the ID and a property name used as the key stores nothing. - **Create Property** Creates a custom contact property. The type is fixed at creation and cannot be changed afterward, and each type carries its own length or format rules. Used when a new data point starts arriving and campaigns need to select on it. - **Update Property** Renames a property or changes its description. The type cannot be edited, so a property created with the wrong type has to be replaced and its values rewritten. Used for content maintenance. - **Delete Property** Deletes a property and the values stored against it. A property in use by a webform is refused rather than detached. Used in cleanup after confirming nothing references it. ### Lists 5 - **List Lists** Returns a page of contact lists with the contact count and open rate of each. Used for discovery and for reporting on audience health. - **Get List** Reads one list with its contact count, status, and open percentage. Used before a send to confirm the audience is what the flow expects. - **Create List** Creates a contact list. The name accepts a restricted character set, so a name carrying other punctuation is rejected rather than sanitized. Used when a workflow provisions an audience for a new campaign or event. - **Update List** Renames a list. Used for housekeeping when naming conventions change. - **Delete List** Deletes a list. Refused while the list is used by an active campaign, automation, or webform, so those references have to be cleared first. Used in cleanup. ### Tags 4 - **List Tags** Returns a page of the account's tags, which apply to both contacts and campaigns. Used to resolve tag IDs before an audience is built. - **Create Tag** Creates a tag for assigning to contacts and campaigns. Used when a workflow introduces a new segmentation dimension. - **Update Tag** Renames a tag. Contacts and campaigns carrying it keep it, because the assignment is stored against the tag ID rather than its name. Used for taxonomy maintenance. - **Delete Tag** Deletes a tag and removes it from every contact and campaign that carried it. Used in cleanup, with the audience impact checked first. ### Segments 3 - **List Segments** Returns a page of segments with how many contacts each currently matches. A segment is a dynamic filter evaluated at send time rather than stored membership. Used to size an audience before a campaign is built. - **Create Segment** Creates a segment from a rule set, with a match mode deciding whether every rule must hold or any one of them. Rules cover contact details, custom properties, campaign activity, and list membership. Used to build audiences programmatically from criteria that live in another system. - **Update Segment** Updates a segment's name, match mode, or rules. The rules replace the stored set rather than adding to it, so the complete list travels every time. Used to keep an audience definition in step with a changing business rule. ### Senders, Webforms and Account 4 - **List Senders** Returns your verified sender addresses with their names. Only an address listed here may be used as the From on a campaign or a transactional send, which makes this the first check when a send is refused. Used as a pre-send guard. - **List Reply Emails** Returns your active reply-to addresses, which are separate records from senders. Leaving a campaign's reply address empty sends replies to the sender instead. Used when replies need to reach a different inbox from the one that sent. - **List Webforms** Returns a page of webforms with their view, submission, and new contact counts. Only active forms carry an embed code. Used to report on acquisition sources and to find a form to publish. - **Get Account Details** Reads the plan and the contact quota: how many contacts the account may hold, how many are used, and how many remain. Used before a large import, because contacts over the quota are skipped quietly rather than refused loudly. ### Campaigns 12 - **Create Campaign** Creates an email campaign with a name, subject, verified sender, content, and an audience built from lists, segments, or tags, with optional exclusions subtracted from it. The publish flag is what sends it: with the flag off the campaign is a draft, and with it on the campaign is scheduled or sent right away. Pause rules let the send stop itself if engagement falls short on the first slice of the audience. - **Create Campaign Classic** Creates a campaign through the vendor's original route, which takes a narrower set of options: lists and one segment, with no tag audience and no exclusions. Kept for accounts still built around it. Used only where an existing process depends on that shape. - **Update Campaign** Updates a campaign's content, audience, or schedule. A campaign that is already sending will not accept changes to its lists, segments, pause rules, or send rules, and its schedule can only be edited after it is paused. Used for corrections before the send begins. - **Get Campaign** Reads one campaign with its content, audience, schedule, status, and report summary. The connector exposes the record unwrapped alongside the vendor's own nested shape. Used to inspect what is about to go out. - **List Campaigns** Returns a page of campaigns with their content, schedule, status, and report summary. Date filtering matches the modified date for drafts and the scheduled date for everything else. Used for reporting and for finding a campaign by name. - **Schedule Campaign** Schedules a campaign to send. Leaving the scheduled time empty schedules it for the current moment, which sends it, so the time is always written out in full. Used as the send step, after approval. - **Send Campaign Test Email** Sends a proof to a single address or to a saved test group without touching the campaign's real audience. Used as the review step before any approval is asked for. - **List Test Mail Groups** Returns the saved test mail groups, each a set of addresses a proof can go to in one call. Used to route a proof to the right reviewers automatically. - **Get Campaign Domain Report** Breaks a campaign's results down by mailbox provider, with sent, bounces, opens, clicks, unsubscribes, and complaints per domain. Used to tell a content problem from a deliverability problem at one provider. - **List Campaign Opens** Returns the contacts who opened a campaign, with their current tags and list memberships and the time of the open. Used to build engaged-audience follow-ups. - **List Campaign Clicks** Returns the contacts who clicked a link in a campaign, with the same contact detail as the opens report. Used for intent-based routing to sales. - **List Campaign Unsubscribes** Returns the contacts who unsubscribed through a specific campaign. Used as the number to watch alongside the open rate, and to propagate the opt out to other systems. ### Templates 6 - **List Templates** Returns a page of saved templates, metadata only by default. Including the content also returns the bodies, and the vendor clamps the page size when it does. Used to populate a picker or to audit what is in use. - **Get Template** Reads one template by ID with its name, category, status, and bodies. Used before rendering a campaign from it. - **Find Template** Reads a template by name or by ID, whichever the flow has. Used when a person configured the flow with a template name rather than an identifier. - **Create Template** Creates a reusable template with a unique name and an HTML body, optionally assigned to a category. Used to publish a design system's output into the sending platform. - **Update Template** Updates a template by ID or by its current name. Campaigns already built from it keep the content they were created with. Used to roll a design change forward without touching sent history. - **List Template Categories** Returns the account's template categories, which is where the category identifier comes from. Used when creating templates programmatically. ### Webhooks 7 - **Create Webhook** Registers a URL that Mailercloud posts to when the chosen events happen, so another system learns about a send, open, click, bounce, or unsubscribe as it occurs. Used to drive downstream systems without polling. - **Update Webhook** Updates a webhook's name, URL, and events. The event list replaces the stored one, so the complete set travels every time. Used when the receiving endpoint or its interests change. - **Get Webhook** Reads one webhook with its URL, events, and status. Used to verify configuration during a deployment. - **List Webhooks** Returns a page of webhooks with their URLs, events, and status. Used to audit what is subscribed across the account. - **Toggle Webhook** Turns a webhook on or off without deleting it, which is how an endpoint is taken out of service while it is repaired. Used during downstream maintenance. - **Test Webhook** Sends a sample payload to a URL so the receiving end can be checked before any real event depends on it. Used as the proof step when wiring a new consumer. - **Delete Webhook** Permanently deletes a webhook, after which nothing further is delivered to its URL. Used in cleanup. ### Automations and Reports 3 - **Create Automation** Creates an advanced automation from a graph of nodes: one trigger plus the actions and conditions that follow it. It is saved as a draft unless publishing is turned on, and re-enrollment lets a contact pass through again. Used to provision a standard journey for a new product or segment without rebuilding it by hand. - **Get Automation** Reads an automation with its node-level report: how many contacts entered, completed, and were skipped, plus the campaigns and steps that make it up. Used to monitor a journey and to copy a working node shape. - **Get Inbox Tracking Report** Reads inbox placement results for campaigns over a date range, broken down by mailbox provider. Used to watch deliverability as a trend rather than as an incident. ### Email API 3 - **Send Email** Sends one message through the transactional side of the platform. The From and every reply-to address must belong to a verified sender, which is the usual cause of a refused send. Placeholders are HTML escaped by default, and copied recipients are rendered against the first recipient's variables rather than their own. Used for receipts, notices, and password flows. - **Send Personalized Email** Sends one message to many recipients with per recipient substitution. Each recipient may carry its own merge variables, filled into the subject, the bodies, and the sender name for that recipient alone. Substitution happens in the vendor's worker after the request is accepted, so a broken placeholder shows up in the delivered message rather than in the response. Used for operational mail merges. - **List Email API Inbox Tracking** Returns inbox placement results for transactional sends, with inbox, spam, and missed percentages and a breakdown per mailbox provider. Used to separate transactional deliverability from marketing deliverability. ### Email Verification 5 - **Verify Emails** Verifies up to fifty addresses in real time and returns a verdict, a delivery score, and the checks behind it, including disposable, role, free provider, and catch all flags. A credit is spent on every attempt including one that resolves to unknown. Uses the separate verifier key. Used inline at signup and before a send. - **Upload Verification File** Queues a bulk verification job and returns its identifier, taking either the addresses directly or a file URL to fetch. Nothing is verified when it returns. Uses the separate verifier key. Used for whole-list hygiene runs. - **List Verification Files** Returns your uploaded verification files with their status and record counts. Used to find a running job and to report on hygiene history. - **Get Verification File Status** Reads the progress and result summary of a bulk job: how many records were processed and how many came back deliverable, invalid, or risky. The connector adds a finished flag so a polling loop has one field to test. Used to wait for a job properly. - **Download Verification Results** Downloads a finished job's results into FlowRunner file storage and returns a URL the rest of the flow can read or hand on. A job that has not finished has no results file to serve. Used to move outcomes into a warehouse or a sheet. ## Frequently Asked Questions ### What can FlowRunner do with Mailercloud? FlowRunner agents can run Create Contact, Create Or Update Contact, and Update Contact in Mailercloud, plus 61 more actions. ### Does connecting Mailercloud to FlowRunner require OAuth? No. Mailercloud connects to FlowRunner with an API key, no OAuth flow required. ### Can Mailercloud trigger a FlowRunner workflow automatically? Mailercloud doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Mailercloud?** This integration exposes Mailercloud to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/mailercloud. Site index: https://flowrunner.ai/llms.txt