API integration for Mailjet
We build your Mailjet connector
We wire Mailjet into your product: transactional email, follow-ups and list hygiene. Each message is tied to a business intent; staging does not pollute inboxes.
- Senior product team
- email connectors in production
- from scoping to monitoring
What does the Mailjet API provide and when should you choose Mailjet for application emails?
Mailjet is a French transactional email and marketing platform that lets your application send event-triggered emails: registration confirmation, payment link, event notification, and manage campaigns from the same platform. You choose Mailjet when the marketing team wants to control templates without going through developers, and transactional and campaign emails need to coexist in the same tool with consolidated statistics. The platform is hosted in Europe, which simplifies GDPR compliance.
What our clients build on the Mailjet API
Transactional emails by template
Invite, invoice, reset: TemplateID on the business side, a stable CustomID, variables in the message. The bounce is no longer a lost email.
List hygiene from the webhooks
bounce, blocked, spam, unsub come back down into the product. You stop writing to a dead address, not only inside Mailjet.
Quote follow-up and transactional together
The same authenticated domain, the same unsubscribe. A SaaS that only sends « forgot password » does not need this; a vendor that chases quotes does.
SMS OTP through v4, if the contract is open
A dedicated token, not v3 Basic. A single client for email and SMS breaks the SMS channel on the first call.
What it changes in how you communicate
Engineering in service of a measurable outcome: a business key, a clean list, staging that does not pollute inboxes.
Each send has a business key
Invoice, reset, invite: the notification ties back to the intent, not only the email address.
Staging does not burn reputation
In test, mail is not delivered to real recipients. The production key does not enter CI.
A retry does not double the send
Deduplication lives in your send table. If the queue retries, the user does not get the same message twice.
Marketing and product share the list
One unsubscribe covers both flows. You do not reconcile two bases at month end.
How we ship your Mailjet connector
Scoping
Which messages, what volume, templates or HTML, SMS or not. We settle CustomID, v2 webhooks, and what stays with Resend if native idempotency is a criterion.
Development
Send v3.1, a send table, a stable CustomID, a v2 webhook handler with dedup on MessageID + event + time, keys per environment.
Acceptance testing
SandboxMode in CI, a validated From, independent To (N Messages, not N addresses), 429 with backoff, a webhook URL secret that is not HMAC.
Monitoring
Alerts on bounce and 429, an inspectable dead letter queue, a CustomID dashboard. You see a revoked key before your customers do.
What the Mailjet API allows
- Send v3.1
- Root Messages body, a previously validated From, TextPart and/or HTMLPart or TemplateID. A ceiling of 50 items in arrays (error mj-0008).
- Business CustomID
- An identifier returned in the webhooks, filterable with GET /v3/REST/message. It is the bridge between the ESP and your record, which a bare SMTP never had.
- eventcallbackurl webhooks
- open, click, bounce, spam, blocked, unsub, sent. Version 2: events grouped, at most once per second. Version 1: one POST per event.
- Full ESP, SMS apart
- Contacts, lists, campaigns, templates, stats, inbound parse. SMS v4 lives on /v4/ with a token, no longer v3 Basic.
The vocabulary of the Mailjet API
- CustomID
- The business identifier set at send time, returned in webhooks, filterable on /message. It is correlation, not anti-double-send: a retry POST still sends.
- SandboxMode
- A root property of POST /v3.1/send. The email is not delivered, validation errors still are. Ideal in CI, never with the production key.
- Messages[]
- The v3.1 root array. The To of a single message can see each other. For N independent recipients, N Messages objects, not N addresses in To.
- eventcallbackurl v2
- Grouped webhooks, at most once per second. v1 plus the sent event at high volume saturates your endpoint or Mailjet. The docs push v2.
- mj-0008
- Error if an array (Messages, attachments, headers, variables) exceeds 50 items. The batch is split in the application, not by inflating a single POST.
- Validated From
- The sender must already be validated and active. An unknown From fails. That is a DNS prerequisite (SPF, DKIM) as much as an API one.
The real constraints of the Mailjet API
No documented Idempotency-Key
CustomID correlates, it does not deduplicate. A retry of POST /v3.1/send can double-send. Protection is a send table, or another vendor on that criterion.
No webhook HMAC in the official guide
The guide describes events and fields, no HMAC secret. Authenticating the caller (secret in the URL, IP allowlist, TLS) is designed on the product side. This is not Svix.
Throughput figures are not public
429 on overflow, a « high » ceiling on transactional, « much lower » elsewhere. No published req/s. Bulk, cache, sub-accounts, backoff.
HTML only, no generated text/plain
Mailjet does not build the text part for you. Accessibility and spam filters both need TextPart: we send it with HTMLPart, or we own the risk.
Mailjet or Resend for your email?
An ESP (transactional, marketing, contacts, SMS) on one side, an idempotent sending API on the other. It is not an SDK choice.
| Criterion | MailjetThis page | ResendSending API |
|---|---|---|
| Product | ESP: tx, marketing, contacts, SMS | Sending API, limited broadcasts |
| Idempotency | CustomID (correlation, not anti-duplicate) | Idempotency-Key, 24 h window |
| Webhooks | eventcallbackurl v2, no HMAC in the guide | Svix, HMAC, svix-* headers |
| Sandbox | Root SandboxMode | resend.dev domain / test keys |
| Residency | Account DPA to be reread | US account, optional eu-west-1 sending |
| Documented throughput | 429, figures not published | 10 req/s per team, IETF headers |
| The right case | Tx + marketing + SMS in one account | Idempotent SaaS transactional email |
The two combine: Mailjet for lifecycle and lists, Resend for a magic link that must not go out twice. It is a scoping trade-off, not a permanent choice.
What we measure on a Mailjet integration
The other sending APIs
If an ESP is not the product you want, these options are worth discussing during scoping.
MailjetWe build your Mailjet connectorThis page
TwilioA programmable carrier: SMS, WhatsApp, voice and OTP out of the box.
BrevoTransactional email and SMS in a French account, templates included.
RingoverFrench telephony: calls, screen pop and SMS from your business software.
ResendWe build your Resend connectorWe combine Mailjet with
The stack that surrounds Mailjet on our projects.
Mailjet integration: your questions
Three steps. Generate one key pair per environment, over HTTP Basic, and a distinct token if SMS v4 is on the agenda. Build a Send v3.1 connector that sets a stable CustomID, splits at 50 messages, sends TextPart and HTMLPart, and refuses to go out until From is validated. Deduplication lives in your send table, because Mailjet documents no Idempotency-Key. Then wire the webhooks on v2, a fast 200 handler, a queue, dedup on MessageID + event + time. With no HMAC in the official guide, the caller is authenticated with a URL secret, an IP allowlist and TLS, and an event never counts as authorisation.
A first useful flow, typically transactional emails by template with CustomID and bounce webhooks, ships in two to three weeks. A complete chain with lists, campaigns, inbound parse, SMS v4 and a preference centre is closer to six to eight weeks. DNS (SPF, DKIM) and the state of the list often weigh more than POST /send. We scope the perimeter up front and give a firm estimate before we start, including the From validation work.
The official webhook guide describes events, fields and v2 grouping, not an HMAC secret. We do not claim one. As it stands, caller authentication is designed on the product side: an unguessable URL, a secret in the URL, an IP allowlist, TLS, strict schema validation. Above all, a bounce received does not cut an address on its own: we deduplicate, we attach the CustomID, we re-check state. That is the sharpest contrast with Resend, whose Svix webhooks carry svix-id, svix-timestamp and svix-signature.
Mailjet is an ESP: transactional, marketing, contacts, templates, SMS v4. CustomID ties a bounce to an order. SandboxMode tests without delivering. Resend is a sending API with an Idempotency-Key for 24 h and signed Svix webhooks. Resend account data stays in the United States, even when sending from eu-west-1. You pick Mailjet when marketing and product share the list. You pick Resend when a magic link must not go out twice, and the US DPA is accepted. Sometimes the answer is both.
Because the To of a single Message object can see each other. For N independent recipients (invoice, reset, invite), you need N objects in the Messages array, not N addresses in To. It is the most common trap on the first v3.1 wiring, along with the ceiling of 50 and SandboxMode forgotten in staging. We add a test that refuses a multiple To on a unit transactional template, and we split batches before mj-0008.
A Mailjet integration project?
Let's talk. 30 minutes to scope your sends, check what the API actually allows and tell you honestly what is feasible.
Discuss my Mailjet project