Your app is in constant, bidrectional communication with Slack—sending messages, listening for responses, and interacting with users.
Here's an overview of the choice you have in how you communicate with Slack.
When you use the Events API directly over HTTP, Slack calls you.
You designate a public HTTP endpoint that your app listens on, choose what events to subscribe to, and voilà: Slack sends the appropriate events to you.
If you want to to publish and distribute your app via the Slack App Directory, you'll want to use the Events API over HTTP.
Sometimes, you can't—or don't wish to—create a static HTTP endpoint for Slack to communicate with your app.
You might be developing behind a corporate firewall, or you might simply have security concerns with that setup.
Even if you're just getting started or only building something for your team, using an SDK with Socket Mode is the quickest way to work with the richest set of Slack platform features. If you'd like to publish and distribute your app via the Slack App Directory, you'll want to use the Events API over HTTP.
Socket Mode allows you to receive events through a private WebSocket, instead of a direct HTTP subscription to events.
By listening on that URL, your app can use the Events API and interactive features of the Slack platform as normal—but you'll receive payloads through that WebSocket URL, constructed at runtime, rather than a static HTTP endpoint.
Socket Mode can be toggled on or off. Whenever you toggle Socket Mode on, you'll only receive events and interactive payloads over your WebSocket connections—not over HTTP.
Socket Mode is only available for apps using new, granular permissions. If you created your app on or after December of 2019, good news: your app already uses the new permissions. Otherwise, you may have to migrate your classic Slack app to use granular permissions before turning on Socket Mode.
The outmoded Real Time Messaging API provides a raw feed of information from Slack.
We recommend using Socket Mode for new apps.