Infrastructure · Every plan
A Bridge is how your applications actually send. Each Bridge sits on top of a Pool, ships with its own SMTP credentials AND a REST API key, and tracks opens / clicks independently. Connect one Bridge per app, revoke individual credentials without affecting siblings, route every send through your dedicated IPs.
Bridges
SMTP + API endpoints
What a Bridge does
A Bridge is the connection layer between your applications and the dedicated IPs underneath — it authenticates the connection, routes the send through the Pool's IPs, and tracks the opens and clicks downstream.
Each Bridge ships with its own SMTP credentials (host, username, password, port, encryption) AND a REST API key (Bearer token). One Bridge per app — the marketing platform gets its own credentials, the order-confirmation service gets its own, the password-reset endpoint gets its own. Revoke one and the others keep working.
Every Bridge is bound to one Pool at creation. Sends through the Bridge route exclusively through that Pool's IPs. The Bridge doesn't pick individual IPs — that's the Pool's job — but it does decide which Pool. Marketing Bridges route through promotional Pools; transactional Bridges route through transactional Pools.
Per-Bridge Track Opens and Track Clicks toggles. Marketing Bridge typically has both on (you want engagement data); transactional Bridge usually has both off (password resets shouldn't have tracking pixels). Toggle independently — each Bridge tracks the way its use case demands.
One Connect · two methods
Each Bridge exposes both methods. SMTP for apps that already speak SMTP — your legacy CRM, your transactional service, any framework that's wired to send mail. REST API for apps that prefer JSON over a Bearer-authenticated HTTP endpoint — newer stacks, server-side functions, anything where opening an SMTP connection feels heavyweight.
Method 1
SMTPDrop the credentials into your framework's mail config. Works with anything that speaks SMTP — Laravel, Django, Rails, Node Nodemailer, WordPress, your CRM's outbound config.
Download credentials as a file from the row actions menu (View SMTP Details → Download SMTP Credentials). Or copy field-by-field from the Bridge detail page.
Method 2
REST APIPOST a JSON payload to the Mumara ONE send endpoint with the Bridge's Bearer token as your Authorization header. Lower-latency than SMTP for high-volume transactional traffic.
POST https://api.mumara.com/v1/send
Authorization: Bearer bm[REDACTED]-69b1...-1511
// JSON body
{
"from": "[email protected]",
"to": "[email protected]",
"subject": "Order confirmed",
"html": "<h1>Thanks!</h1>"
}Sample code in cURL, PHP, NodeJS, Python, and Bash all ship with the Bridge detail page. Pick your tab, copy the snippet, paste it into your app. Multipart/form-data supported for attachments.
Why per-Bridge, not per-account credentials?
The traditional ESP pattern is one set of SMTP credentials per account, shared across every app that sends through the platform. It works until something goes wrong — and then it makes everything harder.
When all your apps use the same credentials, a compromised credential rotates the whole world. Your marketing platform leaks an SMTP password through a misconfigured staging environment; suddenly the password-reset service has to swap credentials too, your CRM has to be updated, your accounting system needs new auth. Mumara ONE's per-Bridge model means revoking the leaked Bridge affects only that app. The transactional service keeps running on its own Bridge with its own creds.
Per-Bridge isolation also enables app-by-app deliverability hygiene. You can see exactly how many sends, deliveries, bounces, and complaints came through the marketing Bridge versus the transactional Bridge — same Pool underneath, but the Bridge-level attribution tells you which app's behavior is driving the numbers. Spot a complaint spike on the marketing Bridge and you know where to look.
And per-Bridge tracking toggles let you do something most platforms force into account-level config: turn off open/click tracking for transactional emails (where pixels would just leak data and slow delivery) while keeping them on for marketing (where engagement data drives optimization). Two Bridges on the same Pool can run with completely different tracking policies. The Pool routes; the Bridge decides what to track.
From zero to first send
Five steps from the dashboard to a live integration. Most of the work is on your side — pasting credentials into your app's config. The platform's part is creating the Bridge and exposing the credentials.
Step 1
Transactional → Bridges → Create a Bridge. Pick a friendly name (e.g., 'marketing-bridge', 'transactional-bridge'). Pick the Pool the Bridge should route through. Save. The Bridge is created and credentials are provisioned instantly.
Step 2
From the Bridges list, click the Bridge name or use View SMTP Details from the row actions. You see SMTP credentials (host, port, encryption, username, password) AND the One Connect API key (Bearer token). Download as a credentials file if you prefer.
Step 3
SMTP: paste host / port / username / password / TLS into your framework's mail config. REST API: drop the Bearer token into your HTTP client's Authorization header. Sample code in cURL, PHP, NodeJS, Python, and Bash ships with the Bridge detail page.
Step 4
Toggle Track Opens and Track Clicks per your use case (marketing: both on, transactional: usually both off). Send your first email. The send routes through the Bridge → through the Pool → through one of the Pool's dedicated IPs.
Step 5
Click the Sending Stats icon on any Bridge row to see Total Sent / Delivered / Bounced / Complaints for that specific Bridge. Per-Bridge stats let you spot per-app issues — a complaint spike on the marketing Bridge vs the transactional Bridge tells you which app's send pattern needs attention.
Code samples
The Bridge detail page includes copy-paste-ready snippets for sending via REST API in five languages. Pick the tab that matches your stack, copy the code, swap the Bearer token in. Most integrations work first try.
One-liner for shell scripts, CI pipelines, and quick tests.
Curl-based PHP snippet — drop into Laravel, WordPress, custom apps.
Modern fetch + axios patterns for Node services and serverless functions.
Requests-based Python snippet — works for Django, Flask, scripts, Lambdas.
Pure shell + curl. Useful for cron jobs and CI/CD-driven sends.
Need to send attachments? The REST API accepts multipart/form-data alongside the standard JSON body. Pass file paths in the attachments array. Custom headers via the headers field.
What's in every Bridge
Bridges are deliberately uniform — same fields on every Bridge, same stats panel, same connection methods. Pick the friendly name, pick the Pool, ship the integration. The platform handles credential rotation, TLS, retry logic, and stats collection.
What account-level credentials cost
The standard ESP model — one set of credentials per account — works fine when you have one app. It starts breaking down the second you have two.
Shared account-level credentials mean a leak in one app forces a credential swap across every app that sends through the platform. Coordinated rotation across services is a real operational burden. Per-Bridge credentials mean a leak in your marketing platform affects only that Bridge — the transactional service keeps running on its own.
Account-wide bounce rate jumps. Is it the marketing platform's stale list segment, or the new password-reset service, or the order-confirmation flow? With account-level credentials, you can't tell. Per-Bridge stats break the question down by app immediately.
Open and click tracking are valuable for marketing but harmful for transactional (slower delivery, leaked tracking domains in receipts). Account-level tracking config forces a compromise. Per-Bridge tracking means marketing Bridges have it on, transactional Bridges have it off — both correct.
Retiring an old service that sends mail? Account-level credentials mean you can't just revoke its access — that would break every other integration too. Per-Bridge means delete the Bridge, the service stops sending, every other app keeps running.
“We run four Bridges: marketing-bridge for the broadcast tool, tx-bridge for order confirmations, reset-bridge for password resets, app-bridge for in-product notifications. Each one has its own SMTP credentials AND API key. When we rotated the marketing-bridge after a contractor's laptop got compromised, the other three never noticed. Try that with shared account-level credentials.”
Verified review
Mumara ONE customer
Common questions
Both. Every Bridge exposes both methods simultaneously. You can connect your CRM via SMTP (because it only speaks SMTP) and connect your custom API service to the REST endpoint (because JSON is cleaner there) — same Bridge, same credentials object, same Pool routing underneath. There's no extra config or upgrade required.
The SMTP credentials (host / port / username / password / TLS) are for apps that connect over the standard SMTP protocol. The API key (a single Bearer token) is for apps that POST to the REST endpoint at api.mumara.com. The API key actually combines the SMTP username, password, and an additional identifier — it's the same underlying credential authority, just packaged for different transports.
Yes. Most operators end up with multiple Bridges per Pool — one Bridge per app, all routing through the same Pool. Common pattern: a Pool called 'transactional' with three Bridges sitting on top — order-confirmations Bridge, password-reset Bridge, in-app-notifications Bridge. Same IPs underneath, isolated credentials per app, separate stats for each.
Each Bridge has Track Opens and Track Clicks toggles, visible both on the Bridges list and on the Bridge detail page. Toggle independently. The platform applies the per-Bridge tracking config at send time — a send through the marketing Bridge gets tracking pixels and tracked links; a send through the transactional Bridge does not. No need to override per-message.
Four headline numbers in the Sending Stats panel: Total Sent, Total Delivered, Total Bounced, and Total Complaints. Same fields as per-IP stats. From those you derive per-Bridge delivery rate, bounce rate, and complaint rate. Useful for spotting which app is driving any rate change rather than seeing only the account-wide aggregate.
Default host is smtp.mumara.com, default port 587 with TLS (STARTTLS). These are the same across every Bridge — what changes per Bridge is the username and password. Some frameworks ask for the host as a different name (mail server, SMTP relay, etc.) — they all mean the same thing.
From the Bridges list, the row actions menu has View SMTP Details, Download SMTP Credentials, and Delete. To rotate, delete the existing Bridge and create a new one with the same Pool — the new Bridge gets fresh credentials. To deprecate an integration, just delete the Bridge and that app stops sending; other Bridges on the same Pool are unaffected.
Yes. The friendly name (SMTP Name) is editable. The internal Pool binding and credentials stay the same — only the display label changes. Useful when you reorganise apps and want the Bridge name to match the new naming convention.
Bridges are available on every Mumara ONE plan. Bridges on plans without dedicated IPs sit on top of shared pools — same SMTP and API methods, same per-Bridge tracking toggles, same per-Bridge stats. Upgrading to plans with dedicated IPs simply binds your Bridges to your own pools instead of the shared one. The credential and code path you ship doesn't change.
Yes. Set the request Content-Type to multipart/form-data and pass file references in the attachments array of the JSON body. The Bridge detail page's Payload tab shows the exact structure. Attachments support standard MIME types; size limits depend on your plan and the receiving ESP's policies — typical limits are 10-25MB per message.
Related
Every Bridge binds to one Pool at creation. The Pool determines which dedicated IPs the Bridge's sends route through.
Read moreThe IPs inside the Pools the Bridges route to. Per-Bridge sends, per-Pool routing, per-IP reputation tracking.
Read moreThe platform-wide REST API for non-send operations — contacts, broadcasts, segments. Bridges expose the per-app send endpoint specifically.
Read moreReal-time DSN delivery events — received, queued, delivered, bounced — attributed to the Bridge that sent each message. Streamed via instant webhooks.
Read moreOpens, clicks, complaints per Bridge, each with bot/proxy verification. Compare engagement quality across your apps.
Read moreDKIM, SPF, DMARC authentication on the From-domains your Bridges send from. Authenticated sending lifts inbox placement across every Bridge.
Read morePer-Bridge stats roll into account-wide reporting. Slice and dice by Bridge, Pool, IP, or message-level detail.
Read moreMumara ONE · Bridges
Bridges ship with every Mumara ONE plan. Create one per app, pick the Pool it should route through (shared or dedicated), drop the SMTP credentials into your config or the Bearer token into your HTTP client. App isolation by design.