Meet our brand new Send API
After months of hard work, here comes the beta version of the Send API 3.1. Now it's easier than ever to send transactional emails programmatically!
We’re an email company. Our core business is to help you send beautiful, responsive emails at scale. And, even if as API lovers we provide you with a variety of tools to handle your campaigns, from parsing your inbound emails to monitor your emails events, we still want to focus on the most important thing: delivering email.
That’s why we created the simple, yet efficient Send API three years ago. It has done an amazing job, but, based on your feedback and our growth, we felt it was time to make the experience even better. You can check out the brand new Mailjet Home for Developers!
Table of content
New detailed error and success payloads
Table of content
Why build a new version?
Everyone who has ever made a call to an API knows that it can quickly turn into a painful experience. Lack of documentation, erratic behaviors, obscure input and response payloads… Let’s be frank. Even if we love to consider ourselves hackers, we’d kill for a pain-free developer experience. That’s why we’ve concentrated on improving our Send API onboarding journey, providing a developer friendly documentation and designing meaningful payloads to help you troubleshoot efficiently.
This was a lot of hard work, especially since we rebuilt the API entirely from scratch, dropping the previous code base written in Free Pascal and architecture for a new tech stack, based on Golang, Cassandra and Kafka, to name a few. This new technical choice isn’t just a modern varnish, but a real focus on performance and scalability.
Time to show you some payloads
We said the onboarding user experience had been improved in this new version of the Send API, didn’t we? Well, it’s time to prove it. Let us demonstrate this with some simple payloads:
Sending one or many messages is as simple as a single HTTP call on the /v3.1/send endpoint. The Send API accepts a JSON body with a single Messages property whose value is an Array composed of as many messages as you want, as long as you don’t include more than 100 recipients (to, cc, bcc) globally.
Piece of cake, heh?
New detailed error and success payloads
Based on our community feedback, we decided to drastically improve the response payloads. From today, we are now performing strict checks on your input payload. For us, it reduces the number of malformed emails entering into our system. And for you, this means you’ll receive some synchronous feedback about what went wrong, efficiently reducing your debugging time.
Errors are generated for each message independently, and block the sending process only for the failing messages.
In case of success, the payload is also more detailed than before, providing, for instance, a MessageHref property, which is a URL pointing to the API endpoint where the message can be retrieved.
Success payloads are sent together with error payloads, in the same order followed by the input payload messages. Checking if and why your messages fail or pass is now a child’s play!
There are plenty of reasons why you’d want to test an email payload without sending a real email: you may be playing around with the API for the first time, or perhaps you’re just testing your code. Sending emails for development purposes comes with a cost, and you’re never protected from the risk of delivering undesired emails to real clients. Plus, isn’t it frustrating to manually delete all the dummy emails you’ve sent, knowing that they’re deducted from your plan’s email quota?
Don’t worry, we have the solution: the brand new sandbox mode. In your input payload, set SandboxMode to true and the Send API will process your messages as if you wanted to send them, without sending them actually. Now, nothing will stop you from testing and troubleshooting all your emails!
Our plans for the near future
What is greater than a new Send-API? A new SendAPI with even more amazing upcoming features! Here’s a quick list of what we’re planning to implement in the coming months:
Email scheduling, which will allow you to safely put the messages in the Mailjet pipe, knowing it will be delivered when the time comes.
MJML direct support (because you shouldn’t be writing your emails in plain HTML anymore).
URL tagging, powered by Google Analytics and other tags.
Spam Scoring (it’s easy to mess up and trigger spam traps without even knowing… and we’re sure you hate spam as much as we do!).
IP management (reserved for the experts!).
Could we have made all these new features available under a premium API plan? Yes. But we think you’d be happier if we provided all of them at no extra cost, so that’s what we’re going to do. ;-) Stay in touch, we will tell you more about it very soon.
Join the beta
Do you feel the urge to test the new version of the Send API? We hear you! Apply immediately to the open beta and be an active contributor to the future of Mailjet Parse Api! Don’t feel like an adventurer? Then you’ll just have to wait for its public release, which is planned for this summer.
You’re an active user of Send API 3.0? Even if we do encourage you to switch to 3.1 to benefit from all the new features, we’ll keep supporting the 3.0 as long as needed, so you’ve got nothing to worry about.
Do you want to learn more about what Mailjet can offer you as a developer? Check out Mailjet for Developers and Subscribe to our dev-only newsletter. We’re also looking forward to seeing you on Twitter. Join us for a chat!
Designing the perfect transactional email with templating
We all agree that email’s an amazing channel to engage with our users on (if you don’t, start by...
How to boost transactional email with our transactional suite
We all know how transactional email is important. Have you ever written a transactional email...