API integration for Slack
We build your Slack connector
We wire Slack into your product: the alert starts from the business file, the Chase button writes into the ERP, the slash command answers without opening a second tool.
- Senior product team
- Slack connectors in production
- from scoping to monitoring
What does the Slack API provide and why integrate it into your platform?
Slack is the reference internal communication tool for technical and product teams. Its API lets your application send a notification to the right channel, create a contextual thread, or receive a command and write into your software. You integrate it so all of that lives in your product: alert born from the business file with no parallel portal, Chase button that records the event in the ERP, slash command that answers from the same system, project channel opened when a deal is created. Slack stays the channel; your application stays the source of truth.
What Slack changes in your platform
Native alert from the business file
Invoice D+7, failed payment, stuck parcel: the channel gets the file with a deep link. The team no longer learns about the incident in a forgotten email.
Chase button that writes into the ERP
The click from Slack records the business event. No second process: the action lives in your system, Slack is not the source of truth.
Slash command without leaving the channel
/dossier returns status as ephemeral. Nobody opens a parallel tool for an order number.
Project channel opened with the deal
When the file is created, the channel invites the right people and drops the link. HR onboarding follows the same pattern, checklist included.
What it changes in your product
Engineering in service of a measurable result: native alert, action into the ERP, same system.
The product notifies where the team already is
Signed quote, failed payment, stuck parcel: the message carries the file. No parallel notification centre.
The click in Slack writes into the business
Slash command, shortcut, modal: chase, approve, create a ticket. The ERP updates on the click.
Ops no longer open a second tool
Order status or the file link answers in the channel. The journey stays in your platform.
The project channel is born with the deal
When the file opens, people and link are already there. No manual creation beside the system.
How we ship your Slack connector
Scoping
Where Slack enters your product: alerts, buttons, slash commands, project channels. Workspaces, scopes, HTTP or Socket Mode. Settled before coding.
Prototype
A staging app wired to a real event from your product and a slash command that already writes into the ERP. You see the journey, not a webhook demo.
Development
A connector wired into your alerts and business actions. HMAC v0 on the raw body, immediate ACK, queue, event_id dedup, Retry-After.
Monitoring
ACK rate, 429s, app_rate_limited, rejected signatures. Signing Secret rotation and separate staging / prod apps.
What the API brings to your platform
- Push the alert from the product
- chat.postMessage and chat.update feed the channel with the file. Alert bursts go through the Web API, not the incoming webhook at 1/s.
- Receive the action into your system
- Events API HTTP or Socket Mode: the Chase click, the mention, the targeted message come back into your application.
- Business slash commands and modals
- A command in Slack reads or writes into the ERP. It is no longer a one-shot webhook glued to a channel.
- Open the channel at the right moment
- conversations.create and users.lookupByEmail: the project channel is born with the deal, the right person gets the DM.
Slack API vocabulary
- Signing Secret
- The app HMAC secret. Basestring v0:{timestamp}:{raw body}, X-Slack-Signature header. Parsing JSON then re-signing fails. Replay window: 5 minutes.
- 3-second ACK
- The Events API requires 2xx in under 3 seconds. Under 5% ACK over 60 minutes (and more than 1,000 events/h): the subscription is temporarily cut. ACK first, queue next.
- app_rate_limited
- Cap of 30,000 deliveries per workspace, per app, per 60 minutes. Beyond that Slack emits this event and stops delivering. It is not a Web API 429.
- Socket Mode
- Outbound WebSocket, max 10 per app. Lets you prototype without a public URL. The Marketplace requires HTTP. It is not the load channel.
- Web API tiers
- Tiers 1 to 4 (and special) per method and per workspace, per-minute window. The figure is on each method's page, not in a single table.
- event_id
- Dedup identifier. Slack may retry (3 fast retries, Delayed Events up to 24 h). Without dedup, a Chase button fires twice.
The real constraints of the Slack API
Business logic does not belong in the Events POST
Any synchronous work in the webhook disables the app. Immediate 2xx ACK, persist, worker. Slack writes it in black and white, it is not an architecture preference.
30,000 events per hour per workspace
A message subscription on a large workspace burns the quota before noon. Subscribe to the minimum (app_mention, not global message.*) and say so at scoping.
Incoming webhook is not chat.postMessage
1 request per second on a channel webhook. A burst of alerts goes through the Web API and a single queue per workspace, with Retry-After.
Socket Mode does not pass the Marketplace
10 connections, state, recycling. Useful in staging behind a firewall. In distributed production Slack recommends HTTP, and the Marketplace requires it.
Incoming webhook or Web API?
Two ways to post to Slack. The right choice depends on volume and interactivity, not on how easy the first message is.
| Criterion | Web APIchat.postMessage | Incoming webhook1 req/s |
|---|---|---|
| Documented throughput | Method tier, per workspace | 1 request per second |
| Alert burst | Queue + Retry-After | Immediate 429 beyond 1/s |
| Updating a message | chat.update | No, a new post |
| Buttons and modals | Native interactivity | Display only |
| Target | Channel, DM, per scopes | The webhook's channel |
| Auth | OAuth, xoxb- token | Channel secret URL |
| The right case | Product, alerting, actions | One channel, low volume |
A channel webhook remains useful for a prototype. As soon as Slack becomes an action in your product (burst, button, several channels), we move to the Web API. The outbound queue is unique per workspace in both cases.
What we measure on a Slack integration
The other productivity tools
If Slack is not the action channel of your product, these options are discussed at scoping.
SlackWe build your Slack connectorThis page
JiraThe ticket, when the Slack alert needs to become a tracked file.
NotionThe base and the wiki, when the team still types it by hand.
AirtableThe structured spreadsheet, a fast back office before a real system of record.
MetabaseWe build your Metabase connectorWe combine Slack with
The stack around Slack when we wire it into a product or an ERP.
Slack: your questions
We wire it into your product touchpoints: alert from the file, button that writes into the ERP, slash command, channel when a deal opens. Technically: dedicated Slack app (separate staging and prod), minimal scopes, Signing Secret in a vault. Events handler ACK 2xx under 3 seconds, business work in a queue, event_id dedup. One outbound queue per workspace for chat.postMessage, Retry-After, incoming webhook reserved for low volume. The sensitive part is not the API call, it is the product journey, the HMAC signature and the 30,000 deliveries per hour ceiling.
An incoming webhook posts to a channel, at 1 request per second, with no message update and no button. The Slack API (Web API plus Events API) authenticates an OAuth bot, posts and updates, opens channels, answers a slash command, and receives signed events. A burst of 200 alerts goes through chat.postMessage and a queue, not through a channel URL. The webhook remains a prototype shortcut. As soon as Slack becomes an action in your product, we talk Web API.
Socket Mode (WebSocket, 10 connections max per app) is for prototyping behind a firewall, with no public URL. HTTP, with a verification challenge, is the production channel: ACK under 3 seconds, retries, Delayed Events, and it is what the Marketplace requires. We sometimes start in Socket Mode for an internal demo, then switch to HTTP before opening the app to client workspaces. The same Bolt handles both, provided the business work is already in a queue, not in the handler.
A first useful flow, typically the business alert from your product into a channel with correct signature and ACK, ships in two to three weeks. A complete chain with buttons into the ERP, slash command, channel creation, several workspaces and Marketplace is closer to six to eight weeks. Duration depends mainly on the touchpoints to wire, scopes and the business rule behind each action. We scope the perimeter up front and give a firm estimate before we start.
By not subscribing to message.* on a workspace of several thousand people. Target app_mention, app events and the useful channels. ACK fast so you do not enter the 5% failure zone. On the way out, incoming webhook at 1/s is another cap: the burst goes through the Web API. Since May 2025, apps distributed outside the Marketplace face stricter limits. Scoping lists the events, estimates volume, and puts an alert on app_rate_limited before go-live.
A Slack integration project?
Let's talk. 30 minutes to scope where Slack enters your platform (alert, ERP action, slash command) and tell you frankly what quotas will hold.
Discuss my Slack project