Overview
A client-mode connector for the Mailgun API (Mailgun by Sinch) that sends email from plant data and keeps track of what happened to it. Typical uses are shift reports, alarm digests, maintenance and quality notices, and audit copies, tagged per plant or line so you can filter delivery events and metrics later. The connector also reads and adds suppressions (bounces, unsubscribes, complaints), manages mailing lists for each plant or team, and registers Mailgun webhooks that post delivery events back to a Coreflux server connector. One connector carries 33 events (21 GET, 9 POST, 3 PUT; 9 writes, no DELETE). Topics usemessaging/mailgun/<object>/<verb>; each response is published on <source topic>/response.
The template was checked against Mailgun’s OpenAPI definition and a local mock, and every endpoint was probed on
api.mailgun.net with a dummy key (each answers Mailgun’s authentication error, while unknown paths answer 404). It has not been run with a real API key yet, so status stays blocked until an authenticated smoke passes.Setup
- In the Mailgun dashboard, copy your primary account API key (Account Settings, API Keys), or create a domain sending key on the domain’s settings page. A sending key can only call
MessageSend; every other event needs the account key. - Use a verified sending domain such as
mg.example.com. EU domains changeBASE_ADDRESStohttps://api.eu.mailgun.net, because a domain lives in one region only. - Keep the key in a broker secret (for example
MAILGUN_API_KEY) and build the header value in a LoT action withGET SECRET. Never retain topics that carry it.
Authentication
Mailgun uses HTTP Basic auth with the literal usernameapi and the API key as the password. The connector sends Authorization: Basic <value> and takes the value from the payload field basic_auth, which is base64 of api:<key>:
Form and JSON bodies
Sending a message, resending a stored message, creating or updating a webhook and adding or updating a list member take form fields. Pass them URL-encoded inform; the connector sends them as application/x-www-form-urlencoded. Mailgun options use prefixes such as o:tag, o:testmode, h:Reply-To and v:asset, so encode the colon as %3A. Suppression adds and the analytics queries (LogsQuery, MetricsQuery, UsageMetricsQuery) take JSON in body.
Examples
Email maintenance when a press overheats (messaging/mailgun/messages/send):
{"id": "<20261005...@mg.example.com>", "message": "Queued. Thank you."}.
Find failed deliveries from the last day (messaging/mailgun/events/list):
messaging/mailgun/bounces/get; a 404 means it is not suppressed):
messaging/mailgun/webhooks/create):
query and form are sent as given, so URL-encode them. Email addresses in path fields (address, list, member) are used as they are.
Events
Limits
Send options (o:, h:, v: and t: fields) are limited to 16 KB per message. Events and stored messages are kept for at least 3 days (longer on paid plans). Mailgun rate-limits per account and answers 429 when you send too fast; sandbox domains can only send to authorized recipients. The v3 stats and tag endpoints are deprecated, so this template uses the /v1/analytics metrics and logs API instead.
Not packaged
- All DELETE endpoints (domains, webhooks, suppressions, templates, lists, members, connectors) on purpose.
- Attachments, inline images and MIME sending (
messages.mime), which need multipart. - Domain creation and DNS, DKIM keys, IP pools and dedicated IPs, subaccounts, API keys, SMTP credentials, users, alerts, template and connector creation, bulk member uploads and suppression imports.
- Deprecated v3 stats, tags and aggregates; email validation and inbox placement (separate Mailgun Optimize API).
- The incoming webhook direction: Mailgun webhooks post event JSON to a separate
ENABLE_SERVERREST_API connector, which should check Mailgun’s HMAC signature with the webhook signing key.
Suggested branches
feat/rest-api-route-mailgun for the broker template and feat/docs-rest-api-mailgun for this page.
