Events

Inbound events from Slack -- the Events API in production, Socket Mode for local dev, and interactivity payloads from Block Kit

Slack pushes data to your app in two different shapes:

• Events -- things that happened in a workspace (a message was posted, a reaction was added, a channel was created). You subscribe per event type, gated by an OAuth scope.

• Interactivity -- a user acted on a Block Kit component your app rendered (clicked a button, picked an option). One payload per action.

In production, both arrive as a signed HTTP POST to a URL you register in your app's settings (a Request URL for events, a separate Interactivity Request URL for actions), and Worker-side handling is the same for both: verify the signature, then acknowledge with a 2xx inside 3 seconds. See Verifying Requests and The 3-Second Ack for that shared groundwork. Locally, the same two payload shapes can arrive over a WebSocket instead -- see Socket Mode below -- but the payloads themselves don't change, only the transport.

Transport: Events API vs. Socket Mode

Slack offers two transports for events. Pick one per environment, not one for the whole project.

In This Section

• Events API on Workers -- the production path: the url_verification handshake, retries, event dedupe, and subscription scopes

• Socket Mode for Local Dev -- why Socket Mode doesn't fit a deployed Worker, and how to use it while iterating locally

• Interactivity Payloads -- block_actions payload anatomy and how to respond to one