Choosing Slack’s Real‑Time Message Delivery: Events API vs RTM

Decision: Pick the Right Real‑Time Delivery Path

When building an application that reacts instantly to Slack messages, you must decide between two supported delivery mechanisms:

• Events API with Webhooks – the officially recommended, HTTPS‑based endpoint that receives event payloads from Slack.
• RTM API (WebSocket) – a legacy, persistent connection that streams events in real time.

Both methods expose the same event types (e.g., message), but they differ in latency, infrastructure, and future‑proofing. The decision hinges on your constraints:

• Low latency (ideally < 1 s)
• High reliability and graceful handling of outages
• Minimal operational overhead
• Compliance with Slack’s rate limits and security model
• Infrastructure cost and public reachability

Compact Comparison Table

Aspect	Events API (Webhooks)	RTM API (WebSocket)
Delivery Model	HTTP POST to a public HTTPS endpoint	Persistent WebSocket connection from your process
Initial Latency	1–2 s (challenge handshake + HTTPS round‑trip)	Sub‑second (instant frame delivery)
Scalability	Stateless – scale horizontally via load balancer	Stateful – each instance needs its own connection
Reconnection Logic	Handled by Slack; no client‑side reconnect needed	Client must implement exponential back‑off and ping/pong
Rate Limits	Standard Slack limits (1 req/sec per token)	Same limits, but continuous traffic may hit burst limits
Security	Verify signing secret (HMAC SHA‑256) on each request	TLS encryption on WebSocket; no request validation needed
Deprecation Status	Fully supported and future‑proofed	Deprecated; may be removed in future releases
Infrastructure Footprint	Only an HTTPS server (e.g., Nginx, Express)	Continuous process, memory for connection, reconnection code
Typical Use‑Case	Server‑side event handling, microservices, third‑party integrations	Legacy bots, real‑time dashboards, low‑latency bots

Trade‑Offs Explained

• Latency vs Simplicity – RTM delivers events instantly, but you must manage a long‑running socket, handle heartbeats, and recover from drops. The Events API adds a 1–2 s delay but removes the need for persistent connections.
• Scalability – Webhooks are stateless; you can route traffic through a CDN or load balancer. RTM requires one socket per instance, which can quickly exhaust your server resources.
• Operational Overhead – With Webhooks you only need a secure HTTPS endpoint; RTM demands continuous health checks, reconnection logic, and potentially a dedicated process.
• Future‑Proofing – Slack’s documentation encourages the Events API for new apps. RTM is marked “deprecated” and may be removed, making it risky for long‑term projects.
• Security Model – Webhooks let you validate each request with a signing secret. RTM relies on TLS, but you lose the per‑request verification step.

Concrete Implementation: Events API with Webhooks

The following example demonstrates how to set up a minimal Slack app that receives message events via the Events API. It uses Node.js with Express and the @slack/web-api package for verification.

1. Create a Slack app in your workspace and enable Event Subscriptions. Set the Request URL to https://your‑public‑domain/slack/events.
   • Slack will send a challenge payload to validate the endpoint. Your server must echo the challenge back.
2. Install the app into the workspace to obtain an OAuth token with the chat:write and channels:history scopes (or whatever scopes you need). Store the Signing Secret from the app settings.
3. Set up the server:

   const express = require('express');
   const { createEventAdapter } = require('@slack/events-api');
   const bodyParser = require('body-parser');
   
   const app = express();
   const slackSigningSecret = process.env.SLACK_SIGNING_SECRET;
   const slackEvents = createEventAdapter(slackSigningSecret, { includeBody: true });
   
   // Verify the challenge during subscription
   app.use('/slack/events', slackEvents.expressMiddleware());
   
   // Handle message events
   slackEvents.on('message', async (event) => {
     console.log('Received message:', event.text);
     // Your business logic here
   });
   
   // Fallback for non‑Slack requests
   app.use((req, res) => res.status(404).send('Not found'));
   
   const PORT = process.env.PORT || 3000;
   app.listen(PORT, () => console.log(`Listening on port ${PORT}`));
   

4. Expose the endpoint publicly – For local development you can use ngrok:

   ngrok http 3000
   

   Copy the HTTPS URL and update the Request URL in Slack.
5. Test the flow – Send a message in a channel where the app is installed. Slack will POST a message event to your endpoint. Verify the console logs show the event and that the latency (message timestamp vs. event receipt) is within 1–2 s.

Validating the Decision

• Measure latency: log the event.ts from the payload and compare it to the current time at receipt.
• Check rate limits: Slack includes x-app-rate-limit headers in responses; monitor these to stay under limits.
• Confirm security: compute the HMAC SHA‑256 of the raw body using the signing secret and compare to the X-Slack-Signature header.
• Ensure high availability: Deploy behind a load balancer and consider using a serverless function (e.g., AWS Lambda) for cost‑efficiency.

When to Consider RTM

If you need sub‑second delivery and are willing to maintain a persistent process, RTM can still be used. However, you must:

• Implement robust reconnection logic with exponential back‑off.
• Handle Slack’s ping/pong frames to keep the connection alive.
• Respect the socket_mode_enabled flag if you want to use Socket Mode as an alternative.
• Monitor for deprecation notices in Slack’s changelog to avoid breaking changes.

Given the deprecation status and maintenance overhead, RTM is best suited for legacy systems that cannot yet migrate to the Events API.

Conclusion

For new projects, the Events API with Webhooks offers a simpler, scalable, and future‑proofed path to real‑time Slack message notifications. It trades a modest initial latency for reduced operational complexity and aligns with Slack’s recommendation. RTM may still be useful for legacy bots or dashboards that demand instant delivery, but its maintenance burden and deprecation risk make it a less attractive long‑term choice.