Building an email notification system often starts with an “and when this happens, we’ll send an email.” Before you know it, you discover this is more complicated than you initially thought. It’s not your core competency, and you can’t afford to divert engineering time toward email notifications right now. You’re starting to look at a slimmed-down version of what you really want.
Creating the perfect notification strategy is like walking a tightrope of constantly changing do’s and don’ts. Send too few, and you may fail to engage your user base. Send too many, and you may quickly annoy them. Utilize multiple channels for a more holistic strategy and risk overwhelming your user. Focus on a single channel, and they might not notice your messages timeously. Send your notification in the morning, and it could get lost amongst all the others.
Most people who interact regularly with smartphones and tablets are familiar with what a push notification is. They want their calendar application to post an alert to their mobile or desktop interface, for example, whether or not they have the app open or their screen locked. If they want to change when, how, or if they receive notifications at all, they simply adjust those in the application settings. For app developers, push notifications are a great way to keep users engaged with a product.
“Transactional email is complex, and for most teams, it’s a tedious afterthought rather than a first-class citizen,” according to Postmark, an email API provider. When it comes to both transactional and triggered email, many software teams assume that the logical next step is to start building their own notification system. But moving down this path without a clear view of the complexities and the size of the undertaking might not be the best solution for your business.
For software products of every scale, emails are the de facto standard for notifying your users. It’s a fast, cost-effective, and readily accessible channel for reaching your users, especially if you’re sending transactional emails or generating event-driven alerts. In this post, I’ll go over three ways to send emails with Python. Apps can leverage Python for sending emails for an array of use cases.
Need help getting started with an integration? Or curious what we’ve launched lately? With our in-app support center, you have everything you need to build and send notifications in one convenient spot. Check out our new support center here. To see the latest feature releases, what’s in development right now, and what’s on our future roadmap – including updates that don’t make our monthly highlights – visit updates.courier.com.
Almost every web application needs the functionality to send transactional emails in response to various triggers. Events like account registration, password resets, purchase receipts, and user verification are among the many tasks today’s applications need to accomplish via email. These emails are crucial for notifying users of important updates and enabling key user workflows in your application. This post explores three different options for sending email from within a Node.js app.
On February 2nd and 3rd, Shy Ruparel joined me for another Courier and Contentful crossover stream. This time, we decided to play around with an IoT E-ink display and use it to show the latest posts from Contentful and send notifications using Courier. During Tuesday's Contentful Live we started working with the newly released Adafruit MagTag. The MagTag is a 2.9" grayscale E-Ink display that can show data on its screen even when power is removed.
If your application sends emails to confirm new accounts, reset user passwords, or handle billing and invoicing, then it’s sending transactional emails. This kind of functionality is extremely common, so naturally there are a lot of vendors that provide these services. But which transactional email API is right for your application?
