FlowRunner
PricingContact
Theme
Start Free

Mumara Campaigns is a self-hosted email marketing platform you run on your own server. Agents manage contact lists and contacts, schedule broadcasts, pull delivery statistics, and handle suppression, bounces and feedback loops on your installation.

Verified 57 actions API key available
Mumara website Platform Documentation Capability data verified 2026-08-19
A scheduled broadcast finishes and its delivery log is available
Get Broadcast Bounced Stats returns each bounce with the receiving server's own reason text
Agent groups the failures by recipient domain and compares them against the bounce rules
Agent separates single-address failures from a cluster pointing at one whole domain
Agent posts the domain clusters with their SMTP codes and the volume behind each one
A deliverability owner decides whether any of them becomes a suppression entry

What This Integration Enables

Mumara Campaigns is self hosted, which changes what the integration is actually for. There is no shared API host, because the base URL is wherever your copy is installed. More importantly, there is no vendor quietly running the deliverability side of your program on your behalf. The things a hosted platform hides are first class objects here: the mailboxes that collect failed deliveries, the rules that decide whether a given refusal is a hard bounce, a soft bounce or not a bounce at all, the feedback loop mailboxes where providers deliver spam complaints, and three separate suppression lists holding addresses, domains and IP addresses.

That is a lot of machinery to run by hand, and it is exactly the sort of machinery a FlowRunner agent should run continuously. Agents manage lists and contacts, handle custom fields keyed by the account's own tags, create and schedule broadcasts, and pull per recipient delivery logs where sent, delivered, bounced, complained, delayed and injected are separate flags rather than one status. They read bounce reasons in the receiving server's own words, maintain classification rules, watch feedback loop mailboxes, and keep the suppression lists honest. Teams take sending in house for control. Control is only worth having if somebody exercises it, and an agent exercises it every day rather than during the postmortem.

Without FlowRunner

Sending infrastructure is nobody's job Bounce mailboxes and feedback loops are configured once, then never looked at again
Bounce data dies in a log The receiving server explains exactly why it refused the message and nobody reads it
Suppression is coarse and permanent An address, a domain and an IP all get blocked the same way, and nobody records why

With FlowRunner

The mail plant has an operator Bounce mailboxes, classification rules and feedback loop accounts are checked and reported on a schedule
Bounce reasons drive rules Recurring refusal patterns become classification rules instead of recurring surprises
Suppression carries its reason Every entry is created with a reference that identifies it, and the scope is chosen deliberately

Use Case Scenarios

  • Bounce triage that turns into rules instead of tickets

    After each scheduled broadcast, the agent calls Get Broadcast Stats Summary to confirm the send finished, then Get Broadcast Bounced Stats to read the failures with their SMTP codes and the remote server's own reason text. It groups them by wording rather than by address, because a refusal phrased the same way forty times is a pattern and not forty incidents. Recurring wording that the current rules classify wrongly is proposed as a new bounce rule, including the no-process type that marks a message as not bounced at all, which is how a false positive gets suppressed. The proposal, with sample messages attached, goes to Slack. Confirmed rules are written with Create Bounce Rule.

  • A contact sync where the write does not sprawl

    Customer records live in PostgreSQL and need to reach the right list. The agent resolves each person by address, and here it is careful about which route it uses, because Mumara's two by-email routes have opposite defaults: the update route acts recursively across every list unless told otherwise, and the delete route acts on only the first match unless told otherwise. The agent sets both explicitly every time rather than relying on either default. Custom field values go through Additional Fields keyed by the tags returned from Get Custom Fields, resolved once at the start of the run.

  • Infrastructure that reports on itself

    A weekly health flow reads the parts of the installation that fail silently. Get Bounce Addresses lists the bounce mailboxes and the agent checks that processing and active are both switched on, because both default to off and a mailbox added without them is configured and does nothing. Get FBL Accounts does the same for feedback loop mailboxes, whose status flag also defaults to off and is named differently for the same idea. Get Activity Logs is read for logins and changes nobody announced. The digest lands in Google Sheets with a short note per finding, and anything that looks like drift gets raised rather than fixed automatically.

Human-in-Loop Highlight

Suppress does not only take an address. It takes a whole domain or an IP address, and its scope parameter accepts a value meaning global, which applies the entry across every list on the installation. A cluster of forty bounces at one company almost always means that company had a bad afternoon with their mail server, not that they stopped being customers, and suppressing the domain globally quietly ends every conversation with everybody who works there. The reversal is worse than it sounds: Delete Suppressed requires only the list type, and everything that narrows the deletion is optional, so the undo for one over-eager entry is a route whose default behavior is to empty the entire suppression list of that kind. That is a self hosted installation. Nobody else has a copy.

So the agent does the analysis and stops before the write. It posts: "Forty-one hard bounces from northwind.co on last night's send, all carrying the same temporary mailbox refusal, and nine of those addresses opened mail from us last week. Suppress the domain globally, suppress the nine confirmed-dead addresses individually, or hold everything for twenty-four hours and re-test?" A deliverability owner answers. The grouping, the SMTP code reading, the cross-reference against recent engagement and the reference string that will make the entry findable later are all the agent's work. The decision to stop mailing a company 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

57 actions

Contact Lists

6
  • Get Contact Lists Reads the contact lists with each list's subscriber total and group. Admin rights are needed to read across users, and per list permission is needed to read one.
  • Get Contact List Reads one contact list. This route does not answer JSON in the ordinary way, delivering the list as a JSON document inside a string behind a prefix, so this action strips and parses it and returns a proper object.
  • Create Contact List Creates a contact list. The bounce address, where failed deliveries arrive, is required alongside the owner and reply addresses, so a list cannot be created without a full sender identity.
  • Update Contact List Changes a contact list. Only the fields given are changed, but leaving the additional fields empty keeps the existing custom field assignment while sending it replaces the assignment.
  • Delete Contact List Deletes a contact list. A list still used by a trigger or a segment is refused, with the vendor asking you to unlink it first, and that refusal arrives as an error status rather than a failing status code.
  • Delete List Group Deletes a group of contact lists. A switch decides the fate of the lists inside it: without it they are moved to unsorted, with it they are deleted along with the group.

Contacts

10
  • Get Contacts Reads contacts. Without full details the answer carries only each contact's ID and address, because custom field values come only when asked for.
  • Get Contact Reads one or more contacts by ID. Several IDs can be given at once and the answer is a list either way.
  • Create Contact Adds a contact to a list. Custom field values go in the additional fields object keyed by the field's tag, and the answer echoes the bounced state back as a string rather than the number that was sent.
  • Update Contact Changes one contact by ID. Only the fields given are changed.
  • Update Contact By Email Changes a contact found by address. Its defaults are the widest possible: it acts recursively by default, so every contact with this address is updated, and with no list named it acts across every list. Set both explicitly to touch one record.
  • Delete Contact Deletes one or more contacts by ID.
  • Delete Contact By Email Deletes a contact found by address. The recursive switch here defaults off, the opposite of the update route, so without it only the first match is deleted and with it every contact holding that address goes.
  • Mark Contact As Unsubscribed Marks one contact unsubscribed, by contact ID.
  • Mark Contact As Complaint Marks one contact as a spam complaint. The vendor is explicit that a contact marked this way will never receive mail from the system again, so it is not a reversible label.
  • Mark Contact As Bounced Marks one contact as soft or hard bounced. The type is required and only the lowercase words are accepted.

Custom Fields

5
  • Get Custom Fields Reads the account's custom fields. The tag is what a contact payload keys its values by and is the vendor's own slug of the name rather than the name itself, and the type comes back as a word even though it is set as a number.
  • Get List Custom Fields Reads the custom fields assigned to one list. The vendor's documented answer for this route is thin, so what actually comes back is worth checking against your own installation.
  • Create Custom Field Creates a custom field and assigns it to lists. Values are required for the three choice types and ignored for the rest, and this action refuses a choice field with no values rather than creating an unusable one. Field order is required and decides where the field appears on the contact form.
  • Update Custom Field Changes a custom field. Changing the type to one of the choice kinds needs values with it, and changing away from them leaves the old options in place.
  • Delete Custom Field Deletes a custom field. A field still assigned to a list is refused unless forced, and forcing it removes the field from those lists along with the values held in it.

Broadcasts and Sending

6
  • Get Broadcasts Reads the account's broadcasts, which are the message templates a schedule sends.
  • Create Broadcast Creates a broadcast. Both content versions are required, HTML and text, because the vendor will not accept an HTML only broadcast, and a group name is required too. Creating a broadcast sends nothing.
  • Update Broadcast Changes a broadcast. Only the fields given are changed.
  • Delete Broadcasts Deletes one or more broadcasts by ID. The vendor documents singular and plural forms of this route with the same parameters, and this action calls the plural form, which both pages agree accepts several IDs.
  • Schedule Broadcast Sends a broadcast. With the sending time set to now it starts immediately, and there is no documented route to cancel or pause a running schedule. The target setting decides whether lists or segments are required, a custom sender type makes the four sender address fields required, a later send time must be in the future, and open and click tracking both default to off.
  • Send Email Sends one email immediately to one address, outside any broadcast. Combining the add-contact option with a list also files the recipient onto that list, which is easy to trigger by accident. A validation failure comes back in an unusual shape, with numeric keys rather than the documented result field, and this action reads the messages out of it.

Broadcast Reporting

8
  • Get Broadcast Stats Summary Reads one schedule's headline figures. The rates come back as strings with a percent sign, so they cannot be compared as numbers without stripping it, and the status field tells you whether the send has finished.
  • Get Broadcast Stats Logs Reads the per recipient send log for one schedule, with the message ID and the delivery flags. Sent, delivered, bounced, spammed, delayed and injected are separate flags, so a message can be sent without being delivered.
  • Get Broadcast Opened Stats Reads who opened a schedule's mail, with the opener's IP, country, region, city and user agent. Each row also carries a clicked flag, so an open row can report the click as well.
  • Get Broadcast Clicked Stats Reads which links were clicked in a schedule's mail, with the URL, the clicker's location and the link ID.
  • Get Broadcast Bounced Stats Reads the bounces from one schedule, each with the SMTP code and the receiving server's own reason text. A type field separates hard from soft, and the reason is the remote server's wording rather than the vendor's.
  • Get Broadcast Complaint Stats Reads the spam complaints from one schedule.
  • Get Broadcast Unsubscribed Stats Reads who unsubscribed from one schedule.
  • Get Activity Logs Reads the account's activity log: logins, and what was created or changed, each with a type and a description.

Suppression

3
  • Get Suppressed Reads a suppression list. The type is required and chooses which of the three lists is read, because addresses, domains and IPs are kept separately.
  • Suppress Adds an address, a domain or an IP to a suppression list. The scope parameter decides how far the entry reaches and zero means global, across every list, so leaving it empty is not the same as sending zero. A reference is required and is how the entry is found again for deletion.
  • Delete Suppressed Removes entries from a suppression list. The type is required and everything that narrows the deletion is optional, so with only a type this removes the whole list of that kind. Give an entry ID or a reference to limit it.

Bounce Handling

8
  • Get Bounce Addresses Reads the bounce mailboxes the account polls for failed deliveries. The password field comes back as the installation's own ciphertext, so it is not the password and cannot be reused.
  • Create Bounce Address Adds a bounce mailbox. Bounce processing and the active flag both default to off, so a mailbox added without them is configured and does nothing. A delete option removes each message from the mailbox once processed, which cannot be undone.
  • Update Bounce Address Changes a bounce mailbox. Every field is optional, so only what is given changes.
  • Delete Bounce Addresses Deletes one or more bounce mailboxes by ID.
  • Get Bounce Rules Reads the rules that classify a bounce as hard, soft or not a bounce at all. A default flag marks the vendor's own built in rules, and a sort order decides which rule wins when two match.
  • Create Bounce Rule Creates a bounce classification rule. The reason, details and detailed reason fields each require their matching condition when set. The no-process type means the rule marks the message as not bounced, which is how a false positive is suppressed.
  • Update Bounce Rule Changes a bounce rule. This is the route whose documented success answer differs in shape from every other route, which is why this action treats only an explicit error as a failure.
  • Delete Bounce Rules Deletes one or more bounce rules by ID.

Feedback Loops

4
  • Get FBL Accounts Reads the feedback loop mailboxes, which are where mailbox providers deliver spam complaints. As with bounce mailboxes the password comes back encrypted, and this route is one of the few where the vendor swaps the result and response keys.
  • Create FBL Account Adds a feedback loop mailbox. The status flag defaults to off, so a mailbox added without it collects nothing, and note that the vendor names this field differently here than on the bounce mailbox for the same idea.
  • Update FBL Account Changes a feedback loop mailbox. Every field is optional, so only what is given changes.
  • Delete FBL Accounts Deletes one or more feedback loop mailboxes by ID.

Spin Tags

4
  • Get Spin Tags Reads the spin tags, the placeholders whose value is picked at random per message to vary the content. The tag is the slug the content refers to, and the word list comes back as one string separated by line breaks rather than as an array.
  • Create Spin Tag Creates a spin tag. The placeholder must be unique, and the vendor turns it into a lowercase underscored tag which is what the content refers to, not the placeholder as typed.
  • Update Spin Tag Changes a spin tag. Sending a word list replaces the whole set of values rather than adding to it.
  • Delete Spin Tags Deletes one or more spin tags by ID. Content that still refers to a deleted tag is left with an unresolved placeholder.

Users

3
  • Create User Creates a user under the account. A package is required and decides the user's limits, and a login IP restriction limits sign in to the addresses given, so getting it wrong locks the new user out.
  • Update User Changes a user, found by ID or by email address. The mobile country code becomes required as soon as a mobile number is given, and both the closed and suspended statuses stop the user signing in although only closed is meant to be permanent.
  • Delete User Deletes a user, found by ID or by email address. A type parameter decides whether this can be undone: the soft default keeps the record, and the hard option removes it for good.

Frequently Asked Questions

What can FlowRunner do with Mumara?

FlowRunner agents can run Get Contact Lists, Get Contact List, and Create Contact List in Mumara, plus 54 more actions.

Does connecting Mumara to FlowRunner require OAuth?

No. Mumara connects to FlowRunner with an API key, no OAuth flow required.

Can Mumara trigger a FlowRunner workflow automatically?

Mumara doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Mumara

Free plan, no card required. Connect in minutes.