suhas-headshot

Suhas Deshpande

For many organizations, Slack is the software of choice for business communication. Slack’s ubiquity in modern companies makes it one of the first notification integrations a SaaS company might want to build, possibly after email and mobile push notifications.

In our experience, Slack notifications are a great way to reach business users (as Slack is mostly used in a business context) with time-sensitive alerts or action items while they’re at work. Because the users are already in work mode, Slack notifications are suitable for anything from collaboration on documents and spreadsheets to workflows like approval requests or data access permissions. Slack is less suited for notifications outside of a work context or out of working hours.

To be able to send messages in Slack, a software system must integrate with [Slack’s API](https://api.slack.com). The resulting integration will allow your application to send Slack messages with helpful information to a Slack channel or a direct message thread. Here’s an example of a Slack message coming from [GitHub’s Slack integration](https://github.com/integrations/slack):

![github-slack](//images.ctfassets.net/z7iqk1q8njt4/20nZJwKjHk3HuFbsyPcANb/0fdc352178ee450eaab124d5b747c436/github-slack.png)

Here’s another example of a Slack integration from [Salesforce](https://help.salesforce.com/s/articleView?id=sf.digital_hq_slack_rn_approvals.htm&type=5):

![salesforce-slack](//images.ctfassets.net/z7iqk1q8njt4/1GKPrZsIjHdfb8u9mStEBt/7827b2be4ceb4b9325dafe8ac685c50b/salesforce-slack.png)

Many organizations don’t quite know what to expect when building an integration for sending messages from their SaaS product to a Slack channel or a direct message. In this post, we offer details for developers who are planning to build a Slack integration for their product.

## Technical aspects of a Slack integration
From a technical perspective, Slack offers a fairly conventional HTTP REST API, which will be straightforward to understand for developers who deal with web systems. The functionality made available through the API is extensive, and there are complex parts to it, but most Slack integrations for SaaS will likely only need to send messages. Messages are the core of Slack’s functionality, but we cover other actions that your app might need to take in Slack below.

For sending messages, the [Sending Messages guide](https://api.slack.com/messaging/sending) in the Slack API documentation is a helpful starting point. The steps required to send a message are:

1. Create a Slack app.
2. Request the correct permissions from the user.
3. Compose the message using one of Slack’s message types (or [blocks](https://api.slack.com/reference/block-kit/blocks)).
4. Send the message via an API call.

The main way to send a message is the POST chat.postMessage endpoint, but it’s also possible to use other endpoints with slightly different functionality: the [chat.postEphemeral](https://api.slack.com/methods/chat.postEphemeral) endpoint, for example, sends messages that are only visible temporarily and for a specific user (helpful for things like error messages). It’s also possible, and in some cases easier, to send messages using an [incoming webhook](https://api.slack.com/messaging/webhooks).

Beyond sending messages, other functionality that you can implement with Slack’s API includes:

* Slash commands — simple chatbot functionality via commands in Slack DMs or channels
* Editing messages that have already been sent — for example, if information has been updated
* Bots that respond to direct mentions and interactions — for example, [Hubot](https://slack.dev/hubot-slack/) is an implementation of such a bot used by hundreds of teams
* Bots that monitor all message traffic in a specific Slack channel or direct message thread (less common due to how inefficient it is to scan all messages in high-volume Slack channels)

Many software teams choose to develop all functionality relating to Slack or another messaging service either in a dedicated microservice (if you use microservice architecture) or at least in a separate section of your monolithic app. The reason to do this is to avoid tightly coupling the way you think about notifications to Slack’s API — doing so could cause issues when the time comes to add support for other messaging APIs. Another reason to use a separate service or namespace for the Slack integration is to implement message retries and other reliability-focused tweaks. Such code would be too complex to include inside your business logic.

In our experience, there are a few points that developers might not be thinking about when building a Slack integration, and we encourage you to consider them:

1. Many of our users run into Slack API rate limits at some point during their usage cycle. So it’s likely that you will need to retry sending a message at some point because of rate limits. Consider including retry functionality from the very beginning.
2. Messages sent by integrations might need to include images or other files, so consider how you’ll handle attachments. Slack offers convenient [file upload](https://api.slack.com/methods/files.upload) functionality via the API that you can use, and it comes with built-in access controls. But you might prefer to [use your own storage](https://api.slack.com/messaging/files/remote). In that case, authenticating requests to files can become painful because you won’t have Slack’s access control mechanism to rely on.
3. Make sure that your system is compliant with relevant regulations, in case you’re sending notifications that include PII or other sensitive data. We wrote about this recently in *[The Developer's Guide to SaaS Compliance](https://www.courier.com/blog/the-developers-guide-to-saas-compliance/)* — check it out. 

## User experience of a Slack integration: Our recommendations
When we advise our customers about Slack integrations, most of our advice centers less on the implementation details and more on the product functionality and customer experience side. We see teams who are building Slack notification functionality for their SaaS focus too much on sending Slack messages and not enough on the value those notifications deliver to their users.

In this section, we offer a few recommendations on designing a helpful Slack notification experience.

### Use Slack status information for optimal notification experience
Something that we find useful for many customers is keeping track of Slack statuses (the little “active” and ”away” indicators you see on people’s profiles). Consider whether you even want to send Slack notifications if someone is marked as being away in Slack — they might not be on their computer, or they might have intentionally changed their status. Is the notification you’re sending in Slack going to be actionable for someone on their phone? For many SaaS applications, the answer is no.

Our recommendation on handling status is to send Slack notifications when the user is active in Slack, and when they are not active, using a different channel like email or mobile push.  We cover the topic of notification routing in *[Building a Routing and Preferences Service for Notifications](https://www.courier.com/blog/routing-and-preferences/)*. 

### Create message templates and have a workflow for updating them
In a SaaS product, it’s very unlikely that you’ll need just one type of Slack message. An app can require tens or hundreds of different notifications to be sent via Slack — and managing such large numbers of messages in your codebase can get tricky.

We recommend using templates instead of hard-coding messages in your application. It’s likely that your message templates will change over time, and you might want to add new notification types as you develop your product. By relying more on templates you can simplify the code review process — it’s easier for a peer to review a template change in a separate file than to jump between templates and code.

Another recommendation is to make templates editable outside of the code review process. This capability will enable colleagues outside of the development team to change and tweak notification templates themselves without the need to commit directly to the codebase.

### Translation and language preferences
Are you going to only offer notifications in one language, or multiple? If you’re offering multiple languages, how does a user configure their preferences? You might want to add functionality within the Slack app that allows users to configure their language settings, or have a section within your web app (outside of Slack) with notification preferences. In any case, you need to store language preferences for each user and, eventually, have a good way to store translated versions of notification text as well.

We also recommend that you consider the translation workflow for notification text — the translators will likely not be able to navigate your codebase due to limited permissions or lack of technical context. Making it straightforward for the translators to work with your notification text will make it faster to implement new notification languages.

## Slack integrations made easier with Courier
In this article, we’ve covered our recommendations for building a successful Slack integration for your SaaS product.

Prefer not to implement the integration yourself?

With Courier, sending a Slack message only requires one API call to Courier’s [send](https://www.courier.com/docs/guides/providers/direct-message/slack/#send-a-message) endpoint. As part of that endpoint, Courier uses [profile information](https://www.courier.com/docs/reference/profiles/) to customize notifications, from individual preferences and personal information to language settings. Courier also offers [templates](https://www.courier.com/features/templates/) that can be created in a well-designed web user interface (with a translation workflow built-in) and [automations](https://www.courier.com/features/automations/) to define more advanced notification logic. And, by the way, once you integrate Courier, you can send other message types — like Microsoft Teams, Discord, email, SMS, and more.

If you’re interested in offloading building a strong Slack integration for your SaaS notification system, [explore Courier](https://app.courier.com/signup) and see if buying might be a better option than building in this case!

*Illustration by [Rebekka Dunlap](https://www.rrebekkaa.com/)*

Get more integrations without having to do more work by buying your notification infrastructure instead of building it from scratch. Explore Courier for free and see if it would be the right fit for your company!

Want to up your integration game for your product notifications?

A little robot with a Slack logo is connected to all types of speech bubble representing notifications

slack-integration-header

In this post, we offer details for developers who are planning to build a Slack integration for their notification system.

slack-integration-thumbnail

Building a Slack Integration for Your SaaS Notification System

nick-headshot

Nick Gottlieb

## TLDR
Easily connect your existing Segment events to trigger and send product notifications.

## Background
We’re excited to announce that we now easily [integrate with Segment](https://segment.com/docs/connections/destinations/catalog/courier), the leading customer data platform.

After 2.5 years and hundreds of customers, our community has convinced us that having additional event sources to act as notification triggers would help expand use cases and reduce the effort required to get up and running with Courier.

Now, Segment and Courier users can:

* Configure Courier as a Segment destination
* Trigger product notifications without writing any additional code
* Take advantage of Courier’s complete product notification platform, including omni-channel routing, dynamic templates, preference management, automations, and more

Don’t use Segment? Remember that you can easily [integrate the Courier Send API into your codebase](https://docs.courier.com/reference/sendmessage) — a single API that can notify your users over any channel. See all of our channel providers in our [Integrations section](https://app.courier.com/integrations).

## Product notification infrastructure without additional code 
While Courier is still a developer API first and foremost, Segment users can now take advantage of the complete Courier platform, including omni-channel routing, dynamic templates, preference management, automations and more by simply adding Courier as a Segment destination. The only requirement is that you are currently sending any events you would want to use to trigger a Courier notification to Segment.

## Courier + Segment use cases
While the ways in which you can use Courier and Segment to automate your product notifications are endless, below are a few highlighted examples of how customers are using Courier and Segment today. Also check out Courier's [case study with Hospitable.com](https://www.courier.com/customers/hospitable-automates-communication-using-courier/) to learn how they use our Segment integration.

### Transactional notification
Using the Segment ‘account created’ or ‘signup’ event, you could send a welcome message to all new users. While the most common channel for welcome messages is email, you could also send a welcome SMS, Slack message, in-app notification, or one of many other channels supported by Courier. You could even set up an automated sequence to nurture new signups as they progress through your product funnel.

![segment-courier-integration-1](//images.ctfassets.net/z7iqk1q8njt4/3PATYalrMWc9Xw128voWkj/207459968e89aa5b23c1117f290bead1/segment-courier-integration-1.png)
*Segment integration in Courier: Segment events, once triggered on your application, can be located in Courier and linked to automations. In this example, our events are linked to the “Account Created/Sign Up” automation that sends a Welcome email to the user when triggered.*

### User activity notification 
Using any segment events you have configured that track user activity that other users may need to know about, for example a product being purchased in a two-sided marketplace, you can easily set up notification automations. One common use case is to send the seller a notification whenever one of their items has been purchased, and then to send the buyer a notification when the seller has shipped their item.

![segment-courier-integration-2](//images.ctfassets.net/z7iqk1q8njt4/JZM5fTEIQ71ahdJzgUJKM/711eda949ab43cb0e271f3ffb0de8825/segment-courier-integration-2.png)
*Segment API sample call: Segment can make calls to Courier that pass along information about how your user is interacting with the application.*

![segment-courier-integration-3](//images.ctfassets.net/z7iqk1q8njt4/6k1EjXyjqfwqZjxOUzq05K/a36a40fd1754bd9e5363ea0d22682ff1/segment-courier-integration-3.png)
*Marketplace automations triggered by Segment API call*

### Action requested notification
You can use any Segment event that requires action from a user to build notification automation in Courier. For example, if your app facilitates employee performance reviews, you may want to begin sending managers both email and Slack reminders to complete their reviews two weeks before they are due. You may then want to send a notification to the manager’s manager, letting them know there are incomplete performance reviews, two days after the due date. All of this is easily achieved, without writing any code, using Courier and Segment together.

## How to get started
The first step is to sign up for a free Courier account and then to configure Courier as a Segment destination. Once that is complete, you can start triggering notifications from Segment events by triggering notification automations from Segment events. A complete getting started guide can be found [here](https://www.courier.com/docs/guides/tutorials/how-to-send-notifications-with-segment).


The Courier logo on the left connects via dotted line to the Segment logo on the right

Courier Segment Integration

We are excited to announce that Courier now integrates easily with Segment, the leading customer data platform.

With Courier's Segment Integration, Developers Create Product Notifications Fast

The Courier and Segment logos connect to each other by dotted line diagonally

Courier Segment Integration - Thumbnail

Courier + Segment Integration: Product Notifications In Minutes

Tejas Headshot

Tejas Kumthekar

Early stage companies are constantly evolving their product to fit the market they operate in. They reach customers to keep them engaged using a high magnitude vector that contributes to their success. Architecting the communications strategy for your product thus becomes an important problem to tackle, which in turn can cause second-order effects like having to trade off the speed of product development iterations. The decisions you would have to make along the path can be hard, confusing and prone to change, and the last thing you want to invest precious time and energy in is these non-core features of your product.

In this blog post, we start by diving into Nodemailer, a module that helps send emails from your Node.js backend, and then we steer our way into writing a transport layer plugin that can help you switch downstream email service providers purely by configuration instead of tedious and sometimes massive code changes.

## Projects that have stood the test of time

In the fast growing tech industry, there’s a special place in the hall of fame for projects that have stood the test of time. [Nodemailer](https://nodemailer.com/about/) is one such project that deserves the well-earned spot. Launched in 2010, not long after Node.js’ inception, Nodemailer has been a go-to dependency for sending email messages for Node.js users. With 14k+ stars and 438k+ usages on [GitHub](https://github.com/nodemailer/nodemailer) and ~1.48M weekly downloads on NPM as of this writing, Node.js developer community has benefited immensely from the project.

Apart from a wide variety of features provided by Nodemailer, it comes with zero dependencies and has been evolving with a security-first mindset. While some of us might think how hard it can be to have zero dependencies, let's remember we’re in a Node.js world where there is a package for every little thing you could possibly imagine. Don’t believe it? Brace yourself while looking at [https://www.npmjs.com/package/is-odd](https://www.npmjs.com/package/is-odd) and [https://www.npmjs.com/package/is-even](https://www.npmjs.com/package/is-even). Yep that’s right - there’s a dependency that can help determine if a number is odd or even. No more complex arithmetic, right? 

On another note, Nodemailer’s security-first development also deserves a round of applause. Those of you who have had to frequently run audits and rack your brains figuring out how to resolve vulnerabilities would agree. Moreover, considering the scale at which projects like Nodemailer have been adopted, even a single vulnerability can have huge negative impacts on the software of the world. One recent example is a [vulnerability in the netmask npm package](https://www.securityweek.com/vulnerability-netmask-npm-package-affects-280000-projects) that could potentially play a hand in malware delivery.

## Extensibility and elegant abstractions are the cruxes

Nodemailer is highly extensible via plugins that can operate on the mail object (pre-processing step), the mail stream (processing step) or the transports (sending step). For the scope of this blog post, we’re mostly concerned about the sending step. [SMTP](https://datatracker.ietf.org/doc/html/rfc5321) is the main transport in Nodemailer for delivering messages - but can be extended using the transport plugin to a different transport mechanism. For example, if you already use [Amazon SES](https://aws.amazon.com/ses/), you can use the SES transport plugin instead of SMTP, which is built-in. Like SES, there are several email service providers out there like SendGrid, Mailgun, Postmark and SparkPost to name a few. In order to cater to the Node.js (and Nodemailer) audience, most of these providers do have a transport plugin of its own should you need to integrate with your tech stack. You can explore through all such plugins with a simple [“Nodemailer transport”](https://www.npmjs.com/search?q=nodemailer%20transport) search query on the NPM registry.

A definite question that always springs to mind is why there are so many email service providers out there and how to choose the one that fits best with your communication strategy. Unsurprisingly, such analysis paralysis is fairly ubiquitous in today’s SaaS world. Calling it a SaaS paradox of choice would hardly be an overstatement. Unless you have theoretically infinite resources at your disposal (read: you’re at a giant like Google or Facebook), these choices can slow down the speed of development significantly and don’t bode well with the “move fast and break things” mantra if you have to go back and forth between email service providers and rewrite your backend stack to accommodate the changeset.

![nodemailer-1](//images.contentful.com/z7iqk1q8njt4/2H94fFdV1jsgw4UVZBHhIv/a9d44c307294b3e2b9b08ac902042415/nodemailer-1.png)
Source: [https://xkcd.com/2224/](https://xkcd.com/2224/)

## Classic build vs buy mindset

In one of our blog posts, we talked about the build vs buy mindset and how it makes a difference, especially if you are a startup - read about it [here](https://www.courier.com/blog/the-three-things-to-never-build-in-your-app/) if you’re curious. The mindset not only makes a difference for your speed of iteration, but also keeps you potentially ahead in the game especially if and when your competitors are adopting buy over build for non-core features of their product. One of the best examples is hosting on AWS vs maintaining on-premises cloud infrastructure - outsourcing cloud hosting to AWS gives you the speed of iteration with no cost of infrastructure maintenance. Imagine all of your competitors are on AWS but you aren’t - it’d certainly make a tremendous negative difference in the long run. While this certainly does not necessarily apply to all the companies out there, it does hold truth for the most. “Disruptive economic events like COVID have caused many people to step back and think about how they want to change strategically. And many have come to the conclusion that they do not want to own and run their own data centers.”, says AWS CFO Brian Olsavsky [https://www.theregister.com/2021/07/30/amazon_q2_2021/](https://www.theregister.com/2021/07/30/amazon_q2_2021/).

An effective communication strategy plays a critical role in maximizing the odds of product success. It's a no-brainer that you have to have a way to reach out to users via Email - but that’s not going to be enough. Customer engagement via text messaging, in-app messaging or direct messaging (think Slack, Whatsapp, MS Teams etc.) has become a necessity in today’s hyper-competitive market. Sooner or later (definitely sooner than you think), having these multiple channels of communication are going to make a difference to your business. As you would scale your product or company, notifications infrastructure has to scale as well in order to handle queuing, scheduling, routing, rendering, and ensuring delivery of messages across multiple channels. Companies like LinkedIn have spent millions to build this infrastructure in-house - depicted quite well in [LinkedIn’s Air Traffic Controller](https://engineering.linkedin.com/blog/2018/03/air-traffic-controller--member-first-notifications-at-linkedin) blog post.

Continuing my mini-rant on the SaaS analysis paralysis, as you’d have probably seen it coming, the paralysis exists on text messaging too - Twilio, Sinch, Plivo and Vonage to name a few providers in the arena. Managing multiple channels and providers to suit the communication strategy you’ve embraced is not a cakewalk. Lets circle back to the never-ending list of email providers and their corresponding Nodemailer transport plugin implementations out there. An easy way to fight the paradox is with a layer of abstraction, such that you can change providers without having to rewrite the code to switch the transport plugins. That’s exactly where Courier comes into picture with its API layer of abstraction and a configurable UI to switch email providers without having to change the code on your end. Needless to say, Courier should expose its own Nodemailer transport plugin which abstracts using a specific email provider plugin. Having this abstraction would imply no vendor lock-in as far as downstream delivery is concerned.

## Show me the code!

Let’s dive right into writing the plugin! [Nodemailer plugin creation](https://nodemailer.com/plugins/create/) (specifically the transport section) and a [Mailgun implementation](https://github.com/orliesaurus/nodemailer-mailgun-transport) would be our reference points. While the core documentation is exhaustive, we’ll keep it relatively simple for the first version of our plugin.

TL;DR: [https://github.com/tk26/nodemailer-courier-transport](https://github.com/tk26/nodemailer-courier-transport) is the code we’ll end up writing.

**Step 1 - Create a new NPM package and adding courier-node as a dependency**

Here's the [Node.js module](https://www.npmjs.com/package/@trycourier/courier) for communicating with the Courier REST API. The source code behind the package is MIT licensed at [courier-node](https://github.com/trycourier/courier-node) repo.

**Step 2 - Configuration prerequisites**

You will need to get a Courier API key to get started. You can sign up and create one for free at [courier.com](https://courier.com). Courier being a middleware, you’d have to configure an email provider of your choice that’d do the actual delivery of the email to the recipient. Stuck in the paradox of choice? We got you! Here’s an [article](https://www.courier.com/blog/best-transactional-email-api-service) we published earlier this year that could be helpful in figuring out. Thereafter, you’d have to create a notification template with email as the channel. [Here’s](https://docs.courier.com/docs/getting-started-sendgrid) how to do it using SendGrid.

**Step 3 - Writing the transport core**

Transports have a **send()** method and **name** and **version** properties. Transport object gets passed to the **createTransport()** method to create the *transporter* object.

    const transport = (options) => {
      const courier = CourierClient({ authorizationToken: options.apiKey });

      const courierSend = input => courier.send({
    	eventId: input.eventId,
    	recipientId: input.userId,
    	profile: {
      	email: input.to,
    	},
      });

      return {
    	name: "Courier",
    	version: packageData.version,
    	send: send(courierSend),
      };
    };

That’s pretty much it for the basic version of the plugin. We’ve pushed the code to [https://github.com/tk26/nodemailer-courier-transport](https://github.com/tk26/nodemailer-courier-transport). feel free to play around with it and reach out with any questions/feedback. It’s open sourced under MIT license so feel free to contribute to the open source project.

**Step 4 - Using the code in your tech stack**

Here’s how things would look in your Node.js backend -

    const nodemailer = require("nodemailer");
    const courierTransport = require("nodemailer-courier-transport");

    // This is your API key that you retrieve from courier.com account (free up to 10k monthly sends)
    const auth = {
      apiKey: "ABCDEFGHIJKLMN",
    };

    const nodemailerCourier = nodemailer.createTransport(courierTransport(auth));

    nodemailerCourier.sendMail(
      {
    	eventId: "courier-event-id", // Configured in Courier UI
    	to: "recipient@domain.com",
    	userId: "unique-user-id",
      },
      (err, info) => {
    	if (err) {
      	console.log(`Error: ${err}`);
    	} else {
      	console.log(`Response: ${info}`);
    	}
      }
    );

Note: We haven’t published the package yet as it is still in a nascent stage. Let us know if you are looking to contribute to the package or want us to publish it so you can use it in your backend. :)

## Key takeaways

Let's summarize the key takeaways from the post. First and foremost - writing and maintaining open source projects that stand the test of time is hard, and projects like Nodemailer are great examples to learn from. Buying over building non-core product features is one of the most important trade-offs you can do to grow your company faster. The sooner you do the trade-off, the higher the returns (and in turn the competitive advantage) you gain. Last but not least, communication strategy is a key pillar in your company’s success - make sure you get it right without compromising on the speed of iteration.

If you’re looking for an easy to integrate, scalable and a reliable communication strategy - sign up for a free [Courier](https://www.courier.com/) account. You build the next big thing and let us handle the communications for you! 🚀


This is the official node.js module for sending notifications with node.js with the Courier REST API.

Check out our Node SDK on Github

a fish attached to a jet pack speeds past the other fish in the sea

nodemailer-header

We start by diving into Nodemailer and writing a transport layer plugin to switch downstream email service providers by configuration instead of code changes.

How to Send Email with Nodemailer Through Multiple Providers

nodemailer-thumbnail

Nodemailer and the SaaS Paradox of Choice

Riley Profile Picture

Riley Napier

who-knew-email-subjects-header

who-knew-email-subjects-thumbnail

Who Knew Email Subjects Are So Complicated?

the-three-things-to-never-build-in-your-app-header

engineer relaxing while an automated system does all the work

Courier [Integrations]

Build your first notification in minutes

Build your first notification in minutes

Product

Developers

Resources

Company