# java-slack-sdk: Bolt for apps, the API client for services

> The Slack SDK for Java splits into two modules with different jobs, Bolt for building interactive Slack apps and slack-api-client for calling the Web API from services you already have. The rest of the project is a wide set of runtime adapters, from Jetty to AWS Lambda to Quarkus, which is where most of the upgrade decisions live.

**slackapi/java-slack-sdk** — Slack Developer Kit (including Bolt for Java) for any JVM language

- Repository: https://github.com/slackapi/java-slack-sdk
- Website: https://docs.slack.dev/tools/java-slack-sdk/
- Stars: 602 · Forks: 236
- Language: Java
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/slackapi-java-slack-sdk

## Pick the module that matches what you are building

The SDK is described as supporting the Slack platform in a Java idiomatic way, and being written in Java so developers can use it in any JVM language including Kotlin, Groovy and Scala. Inside there are two modules, and the README gives an explicit rule for choosing. Bolt for Java is a framework with a simple API for writing modern Slack apps, and the Slack API Client is for when you need a more customised approach. If what you want to do is call Slack APIs in existing services, the recommendation is to use only the Slack API Client. If you are developing a new modern and interactive Slack app, the recommendation is Bolt. The stated reason for Bolt is that the framework enables developers to focus on the essential parts of their apps without being bothered by trifles, which in practice means request verification, acknowledgement and routing are handled for you.

## A Bolt app is a command handler and a server

The smallest Bolt application in the README registers a slash command and starts an HTTP server, and the shape is short enough to read in full. The App is constructed, a command is bound with a lambda that returns an acknowledgement, and the server is started:

```java
package hello;

import com.slack.api.bolt.App;
import com.slack.api.bolt.jetty.SlackAppServer;

public class MyApp {
  public static void main(String[] args) throws Exception {
    // App expects env variables (SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET)
    App app = new App();

    app.command("/hello", (req, ctx) -> {
      return ctx.ack(":wave: Hello!");
    });

    SlackAppServer server = new SlackAppServer(app);
    server.start(); // http://localhost:3000/slack/events
  }
}
```

Two details carry most of the meaning. The App expects the environment variables SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET, and the signing secret is what allows the framework to verify that a request really came from Slack. The comment on the server start line names the endpoint, http://localhost:3000/slack/events, which is the path your Slack app configuration has to point at, so the local port and the route are not incidental details but part of the contract.

## Socket Mode removes the public endpoint

The second example is the same application with Socket Mode enabled, which changes how the app receives events. Instead of running an HTTP server, you construct a SocketModeApp and start it:

```java
package hello;

import com.slack.api.bolt.App;
import com.slack.api.bolt.socket_mode.SocketModeApp;

public class MyApp {
  public static void main(String[] args) throws Exception {
    // App expects an env variable: SLACK_BOT_TOKEN
    App app = new App();

    app.command("/hello", (req, ctx) -> {
      return ctx.ack(":wave: Hello!");
    });

    // SocketModeApp expects an env variable: SLACK_APP_TOKEN
    new SocketModeApp(app).start();
  }
}
```

The App still needs SLACK_BOT_TOKEN, and the SocketModeApp adds SLACK_APP_TOKEN, which is the token used to open the websocket connection to Slack. The practical difference is that your process no longer needs an inbound route, which matters in corporate networks and on serverless platforms where exposing a port is awkward. The repository carries a dedicated module for this, com.slack.api:bolt-socket-mode, and the README points at a separate getting started guide for Bolt with Socket Mode, and the topic tags list websocket and socket mode accordingly.

## The API client is a builder over the Web API

The Slack API Client is described as containing simple, easy to use and flexibly configurable HTTP clients for making requests to Slack APIs, and the example shows the style. A Slack instance is obtained, a token is read from the environment, and a request is built with a lambda that returns a builder:

```java
import com.slack.api.Slack;
import com.slack.api.methods.response.chat.ChatPostMessageResponse;

Slack slack = Slack.getInstance();
String token = System.getenv("SLACK_TOKEN");

ChatPostMessageResponse response = slack.methods(token).chatPostMessage(req -> req
  .channel("C1234567") // Channel ID
  .text(":wave: Hi from a bot written in Java!"));
```

The token is passed per call rather than configured on the client, which is what lets one process talk to more than one workspace, and the response is a typed object, in this case a ChatPostMessageResponse, so the result is something you can inspect rather than a raw JSON string. This is the module to choose when the Slack call is one step inside a service that already exists and has its own HTTP layer, and it is the one to prefer if you are unsure, since the README recommends the client for that case explicitly.

## Every module ships with the same version number

The modules section explains a versioning policy that removes a common source of friction. The table shows all available modules in the SDK, and they all have the same latest version, because the project releases them all at the same time, even in the case where some have no changes apart from updates on their dependency side. So there is no matrix to reason about and no scenario where your Bolt module and your API client are on different versions, which is a real problem with multi-artifact SDKs. All released versions are on the Maven Central repositories, and the README links the artifact coordinates for the client. The trade-off is that a patch release of one module can force you to pull new dependencies into unrelated modules, since the release train moves together.

## The adapters are where your decisions live

The module table is long, and the entries describe runtime adapters rather than features. com.slack.api:bolt is the framework itself, with the most commonly used Servlet environment supported out of the box, and there is a separate bolt-servlet module. There are two Jetty modules, one for the Java EE compatible Jetty 9.x server and one for the Jakarta EE compatible Jetty, plus bolt-jakarta-servlet and bolt-jakarta-socket-mode. Then the serverless and framework adapters arrive, with bolt-aws-lambda for API Gateway plus Lambda, bolt-google-cloud-functions for Google Cloud Functions, and adapters for Micronaut, Helidon SE, http4k, Ktor, and Quarkus in the example directories. The repository root shows the full extent, with bolt-docker-examples, bolt-spring-boot-examples, bolt-kotlin-examples and a bolt-quarkus-examples directory, plus slack-api-client-kotlin-extension and slack-api-model-kotlin-extension for the Kotlin side, and a json-logs directory for structured logging.

## MIT licensed, moving fast, with a big surface

The licence is MIT, so the code can be used in commercial products with attribution and no copyleft obligation on your own code, and the project is published to Maven Central rather than bundled, so consumers pick exactly the modules they need. The release rhythm is quick, with v1.50.0 on 2026-08-07, v1.51.0 on 2026-08-27 and v1.52.0 on 2026-10-01, and the last push was on 2026-10-20, so the project is moving faster than the annual pattern of some platform SDKs. The repository is a large multi-module Maven build with a Maven wrapper, a shared parent pom, a version rules file, metadata for the API models and a scripts directory, and it also carries SECURITY.md, which is where you would look for how to report a vulnerability in a library that handles tokens.

## Conclusion

Adopt java-slack-sdk if your Slack integration lives in a JVM service and you want either the Web API client or a full app framework with typed request builders rather than hand written HTTP calls. Do not adopt Bolt for a script that only needs to post a message, since the API client is the lighter dependency for that, and check the adapter list before you commit, because the servlet, Jetty, Jakarta, Micronaut, Helidon, http4k, Ktor and cloud function modules each pull their own runtime. Verify first which Bolt adapter matches your server, note that the App object reads SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET from the environment, and pin one version across every module, since the project releases them all together with the same version number.

## FAQ

### What is the difference between Bolt for Java and the Slack API Client?

Bolt is a framework for building modern interactive Slack apps, with request handling, verification and routing abstracted away. The Slack API Client is for calling Slack APIs from services you already have, and the README recommends it specifically for that case.

### How do I start a Bolt app that answers a slash command?

Construct an App, register the command with a handler that returns ctx.ack, and start a server such as SlackAppServer. The App expects the environment variables SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET, and the Jetty server serves the events endpoint at http://localhost:3000/slack/events.

### What does Socket Mode change in a Bolt app?

Instead of running an HTTP server you start a SocketModeApp, which needs the SLACK_APP_TOKEN environment variable in addition to SLACK_BOT_TOKEN, and the app connects out to Slack over a websocket. The bolt-socket-mode module provides this.

### Which runtimes and frameworks can Bolt run on?

The module list includes the Servlet environment out of the box, Jetty 9.x and Jakarta Jetty, Jakarta Servlet, AWS API Gateway plus Lambda, Google Cloud Functions, and adapters for Micronaut, Helidon SE, http4k, Ktor and Quarkus, with example directories for Spring Boot, Docker, Kotlin and Quarkus.

### Do all the modules of the Slack Java SDK share a version?

Yes. The README says all modules have the same latest version because they are all released at the same time, even when some have no changes apart from dependency updates. All released versions are published on Maven Central.

## Sources

- [License: MIT](https://github.com/slackapi/java-slack-sdk/blob/main/LICENSE)
- [Project website](https://docs.slack.dev/tools/java-slack-sdk/)
- [README](https://github.com/slackapi/java-slack-sdk/blob/main/README.md)
- [Releases](https://github.com/slackapi/java-slack-sdk/releases)
- [slackapi/java-slack-sdk on GitHub](https://github.com/slackapi/java-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-java-slack-sdk