Send API 3.1 reaches general availability

So, why did we decide it was time for a new version?

Let’s be honest, no matter how much we enjoy finding hacks and workarounds, there’s not a developer out there that wouldn’t prefer a pain-free experience while at work. And yes, we know how painful API calls can get, especially when you combine little to no documentation with erratic behaviors, obscure input, response payloads…

So, to make your life easier and your work more manageable, we decided to focus on providing our users with a seamless Send API onboarding journey. We provide you with a complete documentation made by developers for developers, and meaningful payloads to offer a smooth experience.

And to make this new version even more advanced, with a real focus on performance and scalability, we decided to rebuild it entirely from scratch, moving away from our previous code in Free Pascal and opting for a new tech stack based on Golang, Cassandra and Kafka, to name a few. Sounds good, right?

Awesome! Show me the code, please?

The first thing you’ll notice is how much the onboarding user experience has improved in this new version. Want to see it in action? Check them out here:

Sending messages

Whether you’re sending one or more messages, it will be as simple as making a single HTTP call on the /v3.1/send endpoint. Send API will accept a JSON payload with a single Messages array property containing up to 100 messages. Clear and easy, isn’t it?

New detailed error and success payloads

Thanks to the feedback we received from our community, we decided it was time for a drastic improvement on our response payloads. We now perform strict checks on all your input payload, which means you’ll receive synchronous feedback about what went wrong, in order to cut down your debugging time. On our side, this also means a reduced number of malformed emails entering our system. Check out this example of an error payload.

Something worth noting is that these errors are generated for each message independently, and only the sending process of the failing messages will be blocked.

Our success reporting is also more detailed than it used to be. Success payloads provide, for instance, a MessageHref property, a URL that points to the API endpoint on which to retrieve the message metadata. Tracking your emails straight from the sending has never been easier.

Both success and error payloads are now sent together, in the same order followed by the input payload messages, to make checking the fail or pass status of your messages much easier.

URL Tagging

Sending emails fast, at scale is one side of the business, but being able to monitor how much they perform is critical. Our mission is to offer you all the tools you need to be able to achieve this. Thanks to Send API v3.1, you can now provide us with the proper tracking markers and we'll make sure all the links your emails contain are properly tagged and report back to you.

Sandbox mode

Sending emails for development purposes comes with a cost (yeah, they still count towards your plan’s email quota), and you’re never fully protected from delivering undesired emails to your customers. Whether you’re experimenting with the API for the first time or just checking your code, there might be times when you’d like to test an email payload without having to send a real email. To make your life easier as a developer, we’ve incorporated a brand new sandbox mode. In your input payload, set SandboxMode to true. This will tell the Send API to process your messages as if you wanted to send them, without actually sending them, so you can properly test and troubleshoot your message easily!