Mailjet's API and SMTP routes can produce different final messages even when the visible draft is the same. Compare the rendered MIME content, sender identities and available message references before interpreting mailbox placement. A successful API response or SMTP acceptance does not establish the folder chosen by the receiving mailbox.
Define equivalent message inputs
Choose a non-sensitive application message and save its subject, sender, Reply-To, HTML, plain-text part, links and attachment behavior. Use the same test data for both routes. Decide whether you are comparing two transport submissions of an already rendered message or two complete application implementations.
That distinction matters because an API template path may render differently from an SMTP library that constructs its own MIME. If the application uses separate renderers, the experiment includes those renderers. Do not present it as a transport-only comparison unless content parity has been established.
Identify version and account context
Record the API version and the Mailjet account or API-key context used by each path without recording secrets. Mailjet's current first-email example uses Send API v3.1, while separate documentation covers v3.0. Do not mix property names from different versions when investigating a payload problem.
The SMTP overview assigns responsibility for headers, MIME handling and personalization to the submitting application. Check the actual SMTP library output rather than assuming the API and SMTP paths synthesize the same text alternative or encoding automatically. Save representative generated messages for a meaningful comparison.
Control hidden differences
Compare the visible From and envelope identity, subject encoding, attachment names, text and HTML alternatives, and required unsubscribe headers for the message type. Inventory tracking or template options that may be applied differently. A shared destination URL does not establish the same link rewrite behavior.
Use the same validated sender configuration where supported. Verify actual authentication in received copies; successful login or API authorization only establishes access to the submission service. It does not prove the resulting message passed recipient-side authentication or reached Inbox.
Submit bounded original messages
Create LDM tests for the intended sender and obtain each run's current recipients. Submit one clearly identified fixture through the relevant API implementation and another through SMTP, keeping recipient-provider composition and observation timing comparable. Use the real application logic when that logic is the question.
Retain API response identifiers and SMTP transaction references together with your application's job identifiers. Do not log API secrets, SMTP passwords or full authorization headers. Distinguish an attempted request from a successful provider submission and a later delivery event.
Keep test recipients outside recurring jobs and ordinary subscriber lists. Stop the bounded workflow after the planned messages. This guide performs no requests or sends and assumes no native Mailjet connection with LDM.
Reconcile transport and observation
For each received copy, record its route, message reference, folder and observation time. If the API path is observed and the SMTP path is absent, first inspect the SMTP submission and queue evidence. Absence alone does not establish that the recipient classified the SMTP message as Spam.
If both arrive but placement differs, compare their final content and headers before asserting that the protocol itself explains the result. A small seed panel cannot rank API versus SMTP universally. Application behavior, routing, sender history and recipient context remain relevant limitations.
Frequently asked questions
Does API success mean delivery to Inbox?
No. It is submission evidence. Use subsequent sending events and an actual mailbox observation for the next layers.
Can I compare an API template with a different SMTP draft?
Yes, as a comparison of two full configurations. Do not attribute any difference solely to API versus SMTP without controlling content.
Should I print credentials while debugging?
No. Account labels, sanitized request structure, timestamps and non-secret message references provide useful evidence without exposing authentication material.
Official references
Reviewed 2026-11-05; no protocol benchmark is claimed.