Mailgun-Compatible API

Cloud Server for Email exposes a Mailgun-compatible API endpoint. If your application is already integrated with Mailgun, you can switch to dedicated infrastructure by changing only the base URL and credentials — no code changes required.

The compatibility layer maps Mailgun's HTTP API to the CSE delivery pipeline. Authentication, payload format, headers, response codes, and webhook semantics all follow Mailgun's v3 API specification. The intended use case is migration: applications that were built against Mailgun continue working unchanged, while the underlying infrastructure (IP pools, deliverability tooling, billing) moves to CSE. Mailgun's December 2025 pricing change — Flex doubled from $1 to $2 per 1K — produced a measurable wave of migration interest; this endpoint exists to make those migrations a one-day project rather than a one-quarter rewrite.

Configuration

Replace your Mailgun configuration with:

The base URL change is the only mandatory edit. Existing Mailgun SDKs respect the url or endpoint parameter, which is what the SDK examples below demonstrate. The CSE API key follows the same prefix-and-secret format as Mailgun's keys (key-...) so existing env-var handling and secret storage continue to work without change.

Node.js (Mailgun.js SDK)

Python (mailgun Python SDK)

The Python example uses the requests library directly because Mailgun's HTTP API is simple enough that the SDK overhead is rarely worth it for migration. Both approaches work identically against the CSE endpoint.

Supported Endpoints

The endpoints below cover what most production Mailgun integrations actually call. Endpoints not listed (analytics drill-downs, tag-management operations, some IP-pool management calls) return 501 Not Implemented — the application should handle this gracefully if those calls are present in your codebase. Most migrations discover within the first 24 hours whether any unsupported endpoint is in their critical path.

Behavioural notes

Three places where the compatibility layer differs from native Mailgun in ways that are usually invisible but worth flagging. First, IP routing is controlled by CSE's IP pool configuration rather than Mailgun's tag-based routing — if your code passes o:tag headers expecting per-tag IP separation, the tags are stored but do not affect routing. Second, scheduled delivery (o:deliverytime) is supported but resolution is per-minute rather than Mailgun's per-second — scheduled times round to the nearest minute. Third, webhook signing uses HMAC-SHA256 with the same payload structure as Mailgun, so existing webhook verification code continues working unchanged.

What migration actually involves

The configuration change is the entire code-side migration. Operationally, the migration also requires DNS work and a brief warming period that the compatibility layer does not eliminate. The SPF, DKIM, and DMARC records for your sending domain need updating to authorise CSE's IPs in addition to (or instead of) Mailgun's. The CSE onboarding produces these DNS values; the deploy is usually 5-15 minutes followed by 24-48 hours of DNS propagation.

The IP warming requirement depends on volume. Migrations under 100K/month often use CSE's warmed shared pools and skip dedicated-IP warming entirely. Migrations above 500K/month typically receive dedicated IPs and follow the 4-week warming schedule documented in the onboarding guide. The compatibility layer continues working through both scenarios — what changes is which IPs the messages route through, which is invisible to the application.