Reference · built on requestConnectorMessaging & notifications

Mailgun

Email sending, delivery events, webhooks, and inbound routes through the Mailgun API.

About

Mailgun is an email API from Sinch, served from api.mailgun.net in the US and api.eu.mailgun.net in the EU. You send by posting form fields to /v3/{domain_name}/messages; the response is the message id and the text "Queued. Thank you." Eight webhook events report what followed: accepted, delivered, temporary_fail, permanent_fail, opened, clicked, unsubscribed, complained. Routes turn Mailgun into an inbound mailbox: a filter expression matches incoming mail and an action forwards it to a URL, stores it, or stops evaluation.

Through Fibric, an operator reads inbound mail from a route, follows delivery events for outbound messages, and proposes a send, a scheduled send, or a new route for a person to approve.

This is a reference listing. It documents what Fibric would read from Mailgun and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Webhook posts for accepted, delivered, temporary_fail, permanent_fail, opened, clicked, unsubscribed, and complained, at account or domain level
  • Inbound mail delivered by a route's forward() action as parsed fields: sender, recipient, subject, body-plain, stripped-text, message-headers, attachment-count, attachment-N
  • Event history through GET /v3/{domain_name}/events, filtered by begin, end, event, recipient, tags, message-id, or severity
  • Custom variables (v:) and tags (o:tag) from a send, echoed on its events so a message maps back to your record
  • A stored message fetched from the storage URL on its event, with Accept: message/rfc2822
  • Route definitions through GET /v3/routes and which route an address hits through GET /v3/routes/match

Proposed actions

  • Target capability: propose a send through POST /v3/{domain_name}/messages with o:tag and v: variables set
  • Target capability: propose a scheduled send with o:deliverytime in RFC-2822 format
  • Target capability: propose a rehearsal with o:testmode before the real send
  • Target capability: propose a route with POST /v3/routes: a priority, a match_recipient() or match_header() expression, and a forward() or store() action
  • Target capability: propose editing or removing a route with PUT or DELETE /v3/routes/{id}

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • RFQ intake from a quotes@ address

    A route with match_recipient() forwards mail to Fibric. The operator reads stripped-text and attachments, drafts the quote request record, and proposes it for a person to accept.

    With RFQ Intake

  • Reply to a new lead within the hour

    Inbound mail on a sales route becomes a lead. The operator proposes a reply through /v3/{domain_name}/messages with a v: variable carrying the lead id, so the delivered event closes the loop.

    With Lead Response

  • Reminders that stop on a complaint

    A complained or permanent_fail webhook on a dunning message halts the cadence for that address. The operator proposes a phone or postal follow-up instead.

    With Dunning Cadence

Requirements

  • A Mailgun account with a sending domain added under Domains
  • An API key with rights over that domain, or over the account when routes and webhooks are managed
  • An HTTPS endpoint Fibric operates for webhooks and route forwards, plus the account's Webhook Signing Key to check signatures
  • For inbound mail: routes on a domain whose incoming mail Mailgun receives
Authentication
A Mailgun API key sent in the Authorization header of each request, against the US or EU base URL your account belongs to.

Limits

  • A batch send takes at most 1,000 recipients; send options are capped at 16KB and variables over 4KB are truncated on events and webhooks
  • The Events API is marked as superseded by the Logs API, pages 300 entries at a time, and keeps events at least 3 days
  • Scheduled delivery reaches 3 or 7 days ahead depending on plan
  • A route forward without a 2xx is retried after 10, 15, and 30 minutes, then 1, 2, and 4 hours, and dropped after 8 hours

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Mailgun ↗

Questions and answers

How does inbound email reach Fibric?
Through a route. Its expression uses match_recipient(), match_header(), or catch_all(); its action forwards to a URL, stores the message, or stops. Lower priority numbers run first, and by default every matching route runs. The forward is a POST with parsed fields, retried for 8 hours if you do not return 2xx.
How are webhooks and forwards signed?
Each post carries token, timestamp, and signature. Concatenate timestamp and token with no separator, compute an HMAC with SHA256 using your Webhook Signing Key, and compare the hex digest to signature. Events on a subaccount also carry parent-signature, computed with the primary account's key.
How far back can delivery history be read?
Mailgun states it stores event data for at least 3 days. GET /v3/{domain_name}/events pages through it 300 entries at a time using the paging.next URL. Mailgun marks this API as superseded by the Logs API, so longer history should be kept on your side from webhooks.
Ask about Mailgun

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.