# node-slack-sdk documents four packages and ships nine

> slackapi/node-slack-sdk is a monorepo of small packages, one per Slack API, and the getting-started table names four of them while the workspace configuration lists nine. Everything else worth knowing is in the release mechanics: three packages are versioned and published in the same second, from a changesets workflow.

**slackapi/node-slack-sdk** — Slack Developer Kit for Node.js

- Repository: https://github.com/slackapi/node-slack-sdk
- Website: https://docs.slack.dev/tools/node-slack-sdk/
- Stars: 3,379 · Forks: 686
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/slackapi-node-slack-sdk

## The table names four packages, the workspace holds nine

The getting-started table maps four of Slack's APIs onto four npm packages. The Web API maps to the web-api package, described as sending data to or querying data from Slack through any of over 270 methods. The OAuth surface maps to the oauth package, which covers version 2 OAuth for Slack apps and version 1 OAuth for classic apps. Incoming Webhooks map to the webhook package, for sending notifications to the single channel a user picks at installation time. Socket Mode maps to the socket-mode package, for listening over a WebSocket to incoming messages and a limited set of events. The workspace configuration in the root manifest lists nine entries: those four plus a logger, a types package, a real-time messaging package, and two command line packages named for hooks and for testing. So the table is a starting point rather than an inventory.

## Three packages released within the same six seconds

The three most recent releases are all dated the same evening and are different packages. The web-api package went to 8.2.0, the types package to 3.2.0 and the socket-mode package to 3.1.0, with timestamps a few seconds apart. That pattern is the signature of a changesets workflow rather than three independent releases: the root has a changeset directory, a script that invokes the changesets command line tool, and a version script that applies the changesets, reinstalls, and regenerates documentation in one pass. The practical consequence is that the three packages are designed to move together, so a consumer pinning one of them tightly while floating the others can end up with a combination nobody tested. The root manifest itself is private at version zero point zero point zero, so nothing is ever published from the root.

## Three of the four usage sections defer to Bolt

The usage section has four subsections, and only one contains code. Posting a message with the Web API is shown in full, using a client object exported from the web-api package, a token from the environment, and an identifier that can be a channel ID, a direct message ID, a group direct message ID or a group ID. The other three subsections contain no code at all. Listening for an event with the Events API, responding to interactive messages, and using Socket Mode each consist of a sentence pointing at the Bolt for JavaScript documentation pages. That is the clearest signal in the repository about where the boundary sits: the SDK is the transport layer, and anything involving events, interactivity or a long-lived connection is documented as Bolt's job.

## The posting example names three acceptable scopes

The Web API example constructs a client with a token taken from an environment variable, and the comment above it says the token comes from a Slack app or custom integration and is of the xoxp or xoxb kind. The example then posts to a conversation and logs a timestamp field from the response. The scope requirement is stated as a note directly beneath: for that example to work, the token must have either the bot scope, or one of two chat write scopes. That is the whole authentication story for the simplest possible call, and it is unusually explicit about the fact that the token type and the scopes are two separate decisions. The tip beside it points at a separate hosted builder for prototyping how a message looks before committing to a payload.

## Node v20 is the floor and the type definitions say 18

The stated requirement is Node v20 and higher, with a recommendation to use the latest long term support release, and the documentation is written using syntax and features from that version. The root manifest, however, develops against type definitions for Node in the 18 series. That gap is small in practice, since the floor for consumers is checked at install time rather than by the type definitions, but it does mean the compiler will not warn you about an API that only exists on the older line. It also explains why the documentation can use modern syntax freely: the floor was raised, and the guidance is to track the current release rather than the minimum.

## There is a test suite that talks to production servers

Alongside the unit-level scripts, which fan out across every workspace with a flag to skip packages that do not define them, the repository contains a directory named for production server integration tests. That name is the interesting part: those tests are not mocked, so they exercise the live Slack platform and depend on credentials being present. Everything else about the tooling is conventional and modern. Linting runs a single biome check over the packages directory, with a write variant for fixing. Coverage is configured through a separate file at the root, and the build is a shell script rather than a JavaScript one, with a matching clean target that runs the per-package clean, removes installed dependencies and deletes stray lockfiles. Documentation generation is per package and is part of the version step.

## Installation is one command with two packages named

The installation section gives a single command that installs the web API and socket-mode packages together, and repeats it for yarn, with a comment marking the second line as the alternative. Both are named explicitly rather than being presented as alternatives, which tells you what the authors consider the common combination: something that posts messages and something that listens for them. Installing any single package is equally supported, which is the point of the single-purpose structure. Help is offered in two ways, an issue tracker where the guidance is to search before opening anything new, and a direct email address for Slack developer support.

```shell
$ npm install @slack/web-api @slack/socket-mode

# Or, if you prefer yarn
$ yarn add @slack/web-api @slack/socket-mode
```

One last detail for anyone reading the tree: only two example projects are committed, one for OpenID Connect and one for Socket Mode, which is a small sample set for a repository of this size.

## Conclusion

node-slack-sdk suits an application that needs exactly one Slack capability, since each package can be installed on its own. It does not suit a project that needs event handling and interactivity from the SDK alone, because three of the four usage sections delegate to Bolt for JavaScript instead. Before installing, read the scope requirement on the posting example, decide whether your platform assumption holds given the Node v20 floor against older type definitions, and check which of the nine packages you actually need rather than copying the four-package table.

## FAQ

### What is Slack SDK?

It is a collection of single-purpose packages for building Slack apps in Node.js. The getting-started table maps four Slack APIs to four packages: the web API for sending and querying data, OAuth for authentication, incoming webhooks for a single channel, and socket mode for listening over a WebSocket. The package requires Node v20 or newer.

### What are the key differences between Slack Bolt and the Slack SDK?

The repository does not draw that comparison explicitly, but its structure implies one. The SDK demonstrates a full example only for the Web API, while the sections on the Events API, interactive messages and Socket Mode contain nothing but links to the Bolt for JavaScript documentation.

### Is there an API for Slack?

Yes. The Slack platform offers several APIs, each delivering part of its capabilities, and the web-api package corresponds to the Web API, which the documentation describes as over 270 methods for sending data to or querying data from Slack. Access is through a client object exported from that package, instantiated with a token.

### Can I run Slack locally?

The repository does not describe running Slack itself locally. What it documents is that socket mode listens for incoming messages and a limited set of events over a WebSocket, and that the packages require Node v20 or higher with the latest long term support release recommended.

## Sources

- [License: MIT](https://github.com/slackapi/node-slack-sdk/blob/main/LICENSE)
- [Project website](https://docs.slack.dev/tools/node-slack-sdk/)
- [README](https://github.com/slackapi/node-slack-sdk/blob/main/README.md)
- [Releases](https://github.com/slackapi/node-slack-sdk/releases)
- [slackapi/node-slack-sdk on GitHub](https://github.com/slackapi/node-slack-sdk)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/slackapi-node-slack-sdk