--- title: "Mailkit Integration" description: "Mailkit is a Czech email and SMS platform. Agents manage mailing lists and recipients, schedule campaigns, run transactional and mass delivery and SMS, drive journeys, read reports, and work with the account profile and file manager." url: https://flowrunner.ai/integrations/mailkit date_modified: 2026-09-04T14:28:58-07:00 --- # Mailkit [Email Marketing](https://flowrunner.ai/integrations/category/email-marketing) Mailkit is a Czech email and SMS platform. Agents manage mailing lists and recipients, schedule campaigns, run transactional and mass delivery and SMS, drive journeys, read reports, and work with the account profile and file manager. 50 actions · Custom auth · available [Mailkit website](https://mailkit.eu/) · [Platform Documentation](https://www.mailkit.com/resources/api) · Capability data verified 2026-08-19 1. An erasure request arrives from the privacy inbox and reaches the agent 2. Get Recipient by address returns every record that address holds across mailing lists 3. Get Recipient History pulls the last year of what was sent and how it was answered 4. Get Unsubscribe Status confirms which opt outs are already recorded against the person 5. The assembled evidence goes to the privacy owner with the record IDs listed individually 6. The privacy owner names the records to erase before Wipe Recipient is called on any of them ## What This Integration Enables Mailkit is a Czech email and SMS platform, and it draws a line most senders do not. Deleting a recipient, unsubscribing one, and erasing one are three separate operations with three different meanings. Delete removes the record and records no opt out, so the address can come back on the next import. Unsubscribe is the one that honors consent. Wipe erases the person and their whole history for a right-to-be-forgotten request, replacing the address with a random hash so the reporting stays consistent. Platforms that collapse those into a single delete button leave the difference to whoever clicks it. Mailkit puts it in the API, which is exactly where a workflow can be held to it. The perimeter is drawn in an unusual place too. Mailkit refuses calls from any IP address that is not on the account's own allowlist, whatever the credentials say, so integration here is a deliberate act rather than a pasted key. FlowRunner agents work the whole published surface: mailing lists and recipients, campaign creation and scheduling, transactional and mass sends, SMS, journeys, the reporting stack, and the file manager. The connector handles the platform's own conventions so a flow never sees them, encoding the text values the vendor requires encoded, checking the error field that arrives alongside a successful status, and returning an empty list where the API returns an empty string. What it does not do is decide which of the three consent verbs a situation calls for. That belongs to a person, through a [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) step. ### Without FlowRunner **Erasure handled as an inbox task**: Someone searches the platform by hand, finds what they find, and hopes that was all of it **Opt out and deletion treated as one thing**: A record gets deleted, no consent is recorded, and the address returns on the next import **Mass sends assumed to have worked**: The batch was accepted, so the job is marked done, and the per recipient failures are never read ### With FlowRunner **Erasure assembled as evidence first**: Every record the address holds is gathered and shown before anything irreversible is called **Three consent verbs kept apart**: Delete, unsubscribe, and erase are used for the three different situations they were built for **Batches reconciled against their results**: The agent waits out the reporting delay and reads the per recipient outcomes before closing the run ## Use Case Scenarios ### Purchase behavior that reaches the right topic An order completes in [Shopify](https://flowrunner.ai/integrations/shopify) and the agent calls Add Recipient against the customer mailing list, which updates the record if the address is already there. Custom field values carry the category bought and the order band. Set Recipient Topics then subscribes the customer to the product topics that match, naming every topic explicitly rather than relying on a default, because leaving the topic list empty with the activate-all switch off unsubscribes the recipient from everything. Trigger Journey inserts them into the post-purchase scenario at the event node the marketer configured. Nobody moves a row anywhere. ### A mass send that is actually reconciled A transactional notice needs to reach several thousand customers at once. The agent calls Send Mass Message and stores the request ID, then does not mark the job complete, because the answer only says the batch was accepted. It waits out the vendor's reporting delay, calls Get Mass Send Results, and compares the per recipient outcomes against what it submitted. Failures are grouped by cause and posted to [Slack](https://flowrunner.ai/integrations/slack), and the bounced addresses are written back through Unsubscribe Recipient or held for retry depending on why they failed. A run that used to end at "accepted" now ends at a reconciliation. ### Engagement scores that drive the re-engagement list, at the right cadence Once a day, the agent walks Get Engagement Scores by passing the last recipient ID it saw as the start of the next page, because there are no page numbers here. Scores below the threshold with a worsening trend are assembled into a re-engagement audience and written to a table in [PostgreSQL](https://flowrunner.ai/integrations/postgresql) alongside the score and trend so the campaign can be measured against them later. The agent runs this once daily and no more often, since the platform recalculates the public score once a day however often it is asked, and querying faster only earns a throttle. ## Human-in-Loop Highlight Wipe Recipient is the operation with no way back, and Mailkit is unusually clear about that: the erasure is queued and processed once a day, so a success means the request was accepted, not that it has happened, and nothing in the API cancels it in the meantime. Two more details make it worse to get wrong. Looking a recipient up by address returns every matching record, because the same address can sit on several mailing lists. And a person who submitted an erasure request from one address may exist under two. So the privacy agent assembles and stops. It posts: "Erasure request for j.novak@example.cz. Four recipient records found across three mailing lists: Newsletter, Product Updates, and Webinar 2025. One further record on Newsletter under j.novak+events@example.cz with the same name and postal code. Last activity 11 months ago. Erase all five records, or only the four on the exact address?" The privacy owner decides which records are the same person. The agent then calls Wipe Recipient on exactly those, and writes the request, the evidence, and the decision to the compliance log before it does. Matching records is machine work. Deciding that two addresses are one human being, in a request that cannot be taken back, 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 50 actions ### Mailing Lists 6 - **List Mailing Lists** Returns the account's mailing lists with names, descriptions, and whether each is enabled. A disabled list still holds its recipients but cannot be delivered to. Used for discovery before any list-scoped work. - **Create Mailing List** Creates a mailing list and returns its ID. Used when a workflow provisions a new audience, such as a new event or product line. - **Delete Mailing List** Deletes a mailing list, or empties it while keeping it. The keep switch is off by default, so the default behavior is to remove the whole list rather than its contents. Used in cleanup, carefully. - **Get Mailing List Recipients** Reads a page of a list's recipients with every stored field. Pages by passing the last recipient ID seen rather than a page number. Used for exports, reconciliation, and audience analysis. - **Get Unsubscribed Recipients** Lists everyone who has opted out since a date, with the moment and which unsubscribe group applied. An empty group means a complete opt out rather than a topic-level one, and the address field can hold a mobile number because SMS opt outs arrive through the same list. Used to propagate suppression to other systems. - **Get Engagement Scores** Reads recipients' engagement scores and trends, where the score runs 0 to 5 and the trend shows whether a reader is improving or declining. Recalculated once a day regardless of how often it is asked. Used to build re-engagement and sunset audiences. ### Recipients 12 - **Add Recipient** Adds a recipient to a mailing list or updates one already there, returning the record ID. The confirmation switch decides whether an opt-in email is sent, and recording a recipient without it is only lawful where consent already exists. Used for single-record signup and purchase flows. - **Edit Recipient** Updates a recipient already on a list, found by their record ID. Does not create one. Used when the record is known to exist and the address is not changing. - **Import Recipients** Imports many recipients into a list in one call. The vendor positions it as a bulk update tool rather than the primary insert path. Used for periodic synchronization from a system of record. - **Get Recipient** Reads everything stored about a recipient. Looking up by address returns every matching record across lists; looking up by record ID returns exactly one. Used as the first step of any workflow that needs to know what it is about to change. - **Get Recipient History** Reads a recipient's activity over the past year: what was sent and how they responded. Only the last year is retained. Used for support handoffs and for evidence before a consent decision. - **Move Recipient** Moves a recipient from one mailing list to another and returns both record IDs. The recipient's ID changes, so a flow holding the old one must update it. Used for lifecycle stage transitions. - **Delete Recipient** Deletes a recipient from a mailing list. This is not an opt out: the address carries no suppression afterward and can be added again. Passing an address rather than a record ID deletes every matching record. Used for correcting bad data, not for honoring consent. - **Unsubscribe Recipient** Records an opt out so the recipient is excluded from future deliveries. Sends a confirmation to the recipient by default. Supports a temporary opt out with an expiry. This is the route that honors consent. - **Get Unsubscribe Status** Reads whether a recipient is unsubscribed, which topics they have opted out of, and when a temporary opt out expires. Used before any send decision that touches a previously suppressed address. - **Revalidate Recipient** Re-subscribes a previously unsubscribed recipient. Marked deprecated by the vendor in favor of Add Recipient, and shipped because accounts still call it. Its agreement flag skips the opt-in email entirely and asserts consent was obtained elsewhere, so the channel field should record where. - **Wipe Recipient** Anonymizes and erases a recipient and their whole history for a right-to-be-forgotten request, replacing the address with a random hash so reporting stays consistent. Queued and processed once a day, and cannot be undone. Used only on a confirmed erasure request. - **Set Recipient Topics** Sets which campaign topics a recipient wants. The activate-all switch overrides the topic list entirely when on; with it off and no topics named, the recipient is unsubscribed from every topic. Used for preference center synchronization, always with the topics stated explicitly. ### Campaigns 11 - **List Campaigns** Lists campaigns with their scheduling and settings, including message type, test mode, send date, time zone, and the mailing lists each draws on. Used for discovery and for reporting on what is configured. - **Create Campaign** Creates a campaign and returns its ID. Test mode restricts sending to named test addresses rather than the mailing list, which is the safe way to build one. Used to generate campaigns from a content system rather than by hand. - **Update Campaign** Changes an existing campaign's content and settings. Used for content corrections and for programmatic personalization of a recurring send. - **Schedule Campaign** Schedules a delivery, and sends immediately when the date is given as now. A campaign can hold several scheduled deliveries at once. A time zone is required whenever an actual date and time is given, and a stored query passed here overrides the campaign's own delivery capping. Used for the send itself. - **List Scheduled Deliveries** Lists a campaign's pending deliveries with their moment and time zone. The connector returns an empty list where the platform returns an empty string. Used to confirm what is queued before or after a schedule call. - **Cancel Scheduled Delivery** Cancels a pending delivery so the campaign does not go out. Used as the stop lever between scheduling and sending. - **List Time Zones** Lists the time zones campaign scheduling accepts. Used to resolve a valid zone before scheduling, since one is required for any dated send. - **List Campaign Deliveries** Lists a campaign's past deliveries with the moment each went out. An invalid campaign ID answers empty rather than failing, so an empty result does not prove a campaign was never sent. Used as the entry point to reporting. - **Get Last Campaign Delivery** Returns the ID of a campaign's most recent delivery, which is what the reporting operations take. Used to chain a report to the send that just happened. - **Send Campaign Test Message** Sends one test copy of a campaign to an address, rate limited by the vendor to one message every thirty seconds. Giving a preview recipient renders the personalization properly rather than from nothing. Used as the proof step before a real send. - **Get Campaign History** Reads recent deliveries newest first, each with a preview URL of the message as it went out. Without a campaign ID it covers the whole account. Used for audit and for answering "what did we actually send them". ### Delivery 5 - **Send Message** Sends one message to one recipient through an existing campaign and template, which is Mailkit's transactional route. Subject and body override the campaign's own when given. Attachments travel as a URL or as data. Used for receipts, notices, and one-to-one automated mail. - **Send Mass Message** Sends a campaign to many recipients in one call and returns a request ID. The answer says the batch was accepted, not that anything was delivered. Used for large operational sends that need a per recipient reconciliation afterward. - **Get Mass Send Results** Reads the per recipient outcome of a mass send batch. The vendor asks for a wait of at least half an hour, and a successful status is returned even while the batch is still processing. Used to close the loop on a mass send rather than assuming it worked. - **Send SMS** Sends an SMS through an existing SMS campaign. The split switch decides whether a long message is broken into several charged parts or truncated, and turning on unicode cuts the characters per message sharply. Used for time-critical notices alongside the email channel. - **Trigger Journey** Inserts a recipient into a journey scenario at an event node, or releases one from a wait node immediately. Used to let an outside system drive a journey that Mailkit runs. ### Reporting 11 - **Get Account Report** Reads the account's campaign reporting overview for a date range, campaign by campaign. Used for periodic performance summaries. - **Get Campaign Report** Reads one campaign's reporting across a date range, one row per delivery, with sends, reads, clicks, and spam reports. Used to compare deliveries of a recurring campaign. - **Get Delivery Report** Reads the totals for one delivery: sent, delivered, failed, read, clicked, conversions, and revenue. The unique counts are reported separately from the totals that include repeat opens. Used as the standard post-send summary. - **Get Delivery Recipients** Lists the recipients of one delivery with each one's status and read count. Used for follow-up targeting and for support questions about a specific send. - **Get Delivery Feedback** Reads how a delivery's engagement built up over time, bucketed by day, week, or month from the moment it went out. Used to judge send timing rather than only send content. - **Get Delivery Links** Lists every link in a delivery with how it performed. Used to find the link IDs the visitor operation takes, and to see which call to action carried the message. - **Get Link Visitors** Lists the recipients who clicked one particular link in a delivery. Used to build intent-based follow-up audiences. - **Get Delivery Bounces** Lists the addresses a delivery could not reach, with the moment and the mailing list each belongs to. Used to drive suppression and hygiene work. - **Get Raw Messages** Reads raw per message records for bulk export into your own database, paged by the last message ID seen. The vendor discourages it for interactive use. Used for warehouse loads rather than for reporting inside a flow. - **Get Raw Bounces** Reads raw delivery failure records for bulk export, paged the same way. Used for warehouse loads; the delivery bounce operation is the right one for routine integration. - **Get Raw Responses** Reads raw open and click records for bulk export, paged the same way. Used when the analytics team wants the event stream rather than the aggregates. ### Profile and Files 5 - **List Sender Emails** Lists the sender addresses assigned to the account with their status and SPF state. An address only sends when both are right, which makes this the first thing to check when a campaign will not go out. Used as a pre-send guard. - **List Queries** Lists the account's stored queries. A query is what delivery capping is built on, and its ID is what campaign creation and scheduling accept. Used to apply the capping a marketer already configured. - **List Files** Lists the files and folders in the account's file manager. Folders and files arrive in the same list and are distinguished by type. Used to locate assets before referencing them in content. - **Upload File** Uploads a file to the file manager. The response's error field is not purely a failure flag: one value means the file was accepted under a different name because the original was taken, and another means it landed in the root because the folder was not found. Executable extensions are refused. Used to publish generated assets into campaign content. - **Delete File** Deletes a file, or an empty folder. A folder that still holds anything is refused. Used for asset cleanup. ## Frequently Asked Questions ### What can FlowRunner do with Mailkit? FlowRunner agents can run List Mailing Lists, Create Mailing List, and Delete Mailing List in Mailkit, plus 47 more actions. ### Does connecting Mailkit to FlowRunner require OAuth? Mailkit uses a custom authentication method to connect to FlowRunner. ### Can Mailkit trigger a FlowRunner workflow automatically? Mailkit doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Mailkit?** This integration exposes Mailkit 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/mailkit. Site index: https://flowrunner.ai/llms.txt