slackapi/slack-github-action: four ways to get data into a Slack workspace from a workflow

Four ways in

The action is for sending data to Slack and running commands, and the README lists four distinct capabilities, which is the first thing to understand about it.

You can send data with a webhook to start a workflow in Workflow Builder. You can send data using a Slack API method with a secret token with the required scopes. You can send data as a message with a Slack incoming webhook URL. And you can run Slack CLI commands with a service token.

The four are not variations on one thing. A workflow webhook starts a Slack workflow, an API method call reaches the platform's REST surface with your own permissions, an incoming webhook posts a message to a channel, and the CLI runs commands with a service token, which is Slack's machine identity.

That last distinction is the one that matters for a security review. An incoming webhook URL is a bearer credential that posts to one channel, so it is easy to scope and painful to leak, since it lives in a workflow file. A scoped API token can do whatever the scopes allow. A service token identifies a service to the platform and can be used to run commands, so it is the broadest and the one that most needs care. The action's value is that these paths are all implemented consistently, and the documentation has a page for each.

A bundled action, not a package you install

The repository layout reflects how a GitHub Action is actually distributed, and it is different from an ordinary library.

The package is named `@slack/slack-github-action` and marked private, with `main` pointing at `dist/index.js`, and the published files are `action.yml`, the `cli/` directory and `dist/`. The `action.yml` is what GitHub reads to know what the action is and what inputs it takes.

The build script is the tell. It runs `ncc build src/index.js --license licenses.txt --source-map`, and ncc is the tool that bundles a Node project and its dependencies into a single file with a licence file alongside. GitHub Actions run from a checkout, not from an install, so an action has to carry its dependencies with it, and bundling them is the mechanism.

The `cli/` directory in the same package is the second half of the product. The action can run Slack CLI commands, and the CLI is shipped alongside the action so that a workflow can invoke it without the runner having to install anything.

The project is ESM, with `type` set to `module`, and the declared engines are Node 24.11.0 or later and npm 11.6.1 or later, which is a recent floor and means the action needs a current runner.

Releases with changesets, and a script that rewrites the docs

The release process is visible in the scripts, and two of them are unusual enough to be worth explaining.

The `changeset` script runs the changesets CLI, and the `version` script runs `npm run changeset version`, installs, and then runs the docs script. So a release is a changeset version bump plus a documentation pass, and the two are tied together on purpose.

That documentation script is the interesting one. It reads the version out of the package file with `npm pkg get version` and `jq`, tags it as `v` plus that version, and then uses `grep` and `sed` to rewrite every occurrence of `slackapi/slack-github-action@v` in the `docs` and `example-workflows` directories to the new tag. It then does the same for the CLI reference, `slackapi/slack-github-action/cli@v`.

In other words, the documentation and the example workflows always reference the version that is being released, automatically. For a project whose documentation is mostly YAML examples that people copy, that is a real correctness win, because a workflow file pinned to a stale major version is the kind of thing that breaks silently for a new user.

The versioning guidance in the README matches the practice. The project recommends using the latest version for the most recent updates and fixes, and the changes are logged in the release notes with migration guides for updating from `@v1` to `@v2`, `@v3` and `@v4`.

Running it locally, and how it is tested

The development loop does not require pushing to GitHub to try a change, and the script that does it is unusually explicit.

act public --eventpath .github/resources/.actions/event.json --secret-file .github/resources/.env --platform ubuntu-latest=node:24 --container-architecture linux/amd64

That runs act, which executes a GitHub Actions workflow file locally, against a recorded event payload and a secret file, with the runner platform mapped to a Node 24 container on linux and amd64. So the developer sees the same event, the same inputs and the same secrets that the hosted runner would see, which is the difference between testing an action and testing a script that resembles it.

The test suite is the Node built-in runner, with the coverage flag and two reporters, the spec reporter to standard output and the lcov reporter writing to `test/coverage.txt`, running the `test/*.spec.js` files. The `check` script type checks with `tsc --noemit` against a `jsconfig.json`, and linting is done with Biome, `biome check` with a `lint:fix` variant, and the configuration is the `biome.json` file at the root.

So the toolchain is small and current, the Node test runner, Biome, TypeScript for checking and ncc for bundling, and there is a codecov badge in the README.

Where this is the wrong tool

The first wrong case is a script that posts one message. If a CI job needs to say something in a Slack channel, an incoming webhook call with curl is a line, has no Node version requirement, no action pin and no secret to rotate inside the runner. The action earns its place when there are several destinations, several credentials and a need for the same behaviour across many workflows.

The second is a team that has standardised on a different way of talking to Slack. There are other actions and other approaches, and mixing them in one repository means two credential models and two debugging surfaces.

The third is a workflow that must not have a Slack credential at all. A third party action that receives a secret is a third party in your CI, and some security policies will simply not allow a marketplace action to hold a token that can post to your workspace, however official it is. In that case the action is not the problem, but it is still the wrong answer.

The fourth is a pin to an old major version. The project has shipped four major versions and each has a migration guide, which is a sign that the interfaces have changed in ways that matter, and a workflow sitting on `@v1` is missing fixes that the current version has.

On the state of the project, the current release is v4.0.0, published on 2026-07-15, after v3.0.5 on 2026-07-11 and v3.0.4 on 2026-07-10, and the last push to the repository was on 2026-10-11 with the repository not archived. The licence is MIT, the documentation is at docs.slack.dev/tools/slack-github-action, and the repository carries a `CHANGELOG.md`, a `.changeset/` directory for the pending changes, an `example-workflows/` directory of the YAML the documentation points at, and a `.nvmrc` pinning the Node version.

Editorial conclusion

Adopt the Slack GitHub Action if you want your workflows to talk to a Slack workspace without hand rolling webhook calls, since the action handles the credential plumbing for four different Slack surfaces and keeps them consistent across the major versions. Do not adopt it if your only need is posting one message from a script, because a curl call to an incoming webhook is one line, and be careful with the credential you choose, because a service token and a scoped API token have very different blast radii. Verify first which of the four modes you need and what scopes the token requires, that your runner's Node version meets the declared engines of 24.11.0 or later, and that you are on the current major version, since migration guides exist for each of the v1 to v4 jumps.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. slackapi/slack-github-action on GitHub