Electron gives you a full Node.js environment alongside a Chromium renderer, which makes it a natural fit for building a "connector" — a bridge that lets your desktop app talk to Slack, pull data in, push notifications out, and keep a workspace in sync with whatever your app does. But because Electron apps run two processes with very different trust levels (the privileged main process and the sandboxed renderer), building a Slack connector well means thinking carefully about where each piece of Slack logic should live.

This article walks through the architecture, the OAuth flow, the two main ways to receive events from Slack, and the security details that matter most when you're shipping a desktop app to real users.

Why build a Slack connector into an Electron app at all?

Slack connectors inside desktop apps typically solve one of three problems:

1. Notifications and presence: surfacing Slack messages, mentions, or status changes natively, with OS-level notifications instead of a browser tab.

2. Two-way sync: pushing events from your app (a build finishing, a ticket being closed, a form being submitted) into a Slack channel, and pulling Slack messages or slash commands back into your app.

3. Workflow embedding: letting users trigger Slack actions (posting, uploading files, updating a channel topic) without leaving the app they're already working in.

All three depend on the same foundation: a Slack app registered in the Slack API dashboard, an OAuth token scoped to what you actually need, and a reliable way to receive events.

Architecture: keep Slack logic in the main process

A common mistake is calling Slack's Web API directly from the renderer process, the same place your UI code and any third-party scripts run. That means your Slack token — even a well-scoped one — lives in a context that's easier to compromise if the renderer is ever exposed to untrusted content (a loaded web page, a malicious dependency, a compromised preload script).

The safer pattern:

Renderer (UI)  <--IPC-->  Main process (Node.js)  <--HTTPS-->  Slack API

The main process owns:

1. The Slack OAuth flow and token storage

2. All calls to Slack's Web API (@slack/web-api)

3. Any long-lived connection for receiving events (Socket Mode or an HTTP listener)

The renderer only ever asks the main process to "post this message" or "get me the latest channel list" over ipcMain/ipcRenderer, using a narrow, whitelisted API exposed through a contextBridge in the preload script. The renderer never sees the token.

js

// preload.js
const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('slack', {
postMessage: (channel, text) => ipcRenderer.invoke('slack:postMessage', channel, text),
getChannels: () => ipcRenderer.invoke('slack:getChannels'),
});

js

// main.js
const { WebClient } = require('@slack/web-api');
const { ipcMain } = require('electron');

let slackClient; // initialized after OAuth, holds the access token internally

ipcMain.handle('slack:postMessage', async (_event, channel, text) => {
return slackClient.chat.postMessage({ channel, text });
});

ipcMain.handle('slack:getChannels', async () => {
const res = await slackClient.conversations.list();
return res.channels;
});

This keeps contextIsolation: true and nodeIntegration: false intact — the standard, recommended Electron security posture — while still giving the UI everything it needs.

The OAuth flow, adapted for a desktop shell

Slack's OAuth is built around a redirect URL, which is straightforward in a browser but needs a small adaptation in Electron since your app isn't running on a web server the browser can navigate back to.

A reliable approach:

1. Register your Slack app with a redirect URI pointing at a local loopback address, e.g. http://localhost:3939/slack/callback.

2. When the user clicks "Connect to Slack," open the authorization URL in the system browser (shell.openExternal), not an in-app BrowserWindow. Slack's guidelines and most OAuth best practices discourage embedded web views for auth, partly because users can't verify the URL bar or use saved credentials/password managers reliably.

3. Spin up a short-lived local HTTP server in the main process to catch the redirect and grab the authorization code.

4. Exchange that code for an access token server-to-server (still from the main process), then store the token securely.

js

const { shell } = require('electron');
const http = require('http');
const { WebClient } = require('@slack/web-api');

function startOAuthFlow(clientId, clientSecret, scopes) {
return new Promise((resolve, reject) => {
    const server = http.createServer(async (req, res) => {
    const url = new URL(req.url, 'http://localhost:3939');
    const code = url.searchParams.get('code');

    if (code) {
        res.end('You can close this window and return to the app.');
        server.close();

        try {
        const client = new WebClient();
        const result = await client.oauth.v2.access({
            client_id: clientId,
            client_secret: clientSecret,
            code,
            redirect_uri: 'http://localhost:3939/slack/callback',
        });
        resolve(result);
        } catch (err) {
        reject(err);
        }
    }
    });

    server.listen(3939, () => {
    const authUrl = `https://slack.com/oauth/v2/authorize?client_id=${clientId}&scope=${scopes.join(',')}&redirect_uri=http://localhost:3939/slack/callback`;
    shell.openExternal(authUrl);
    });
});
}

Once you have the token, don't write it to a plain JSON file next to your app's other settings. Use keytar (or Electron's safeStorage API, which wraps OS-level keychains — Keychain on macOS, Credential Vault on Windows, libsecret on Linux) to store it in the system credential store instead of app-local storage.

Receiving events from Slack: Socket Mode vs. HTTP endpoints

Slack apps typically get real-time events one of two ways:

Socket Mode opens a persistent WebSocket connection from your app out to Slack, so Slack pushes events to you without needing an inbound HTTPS endpoint. This is by far the better fit for a desktop app: there's no public URL to host, no port-forwarding, no server to run. The @slack/socket-mode package handles this well from the main process.

js

const { SocketModeClient } = require('@slack/socket-mode');

const socketClient = new SocketModeClient({ appToken: SLACK_APP_TOKEN });

socketClient.on('message', async ({ event, ack }) => {
await ack();
mainWindow.webContents.send('slack:newMessage', event);
});

await socketClient.start();

HTTP event subscriptions, by contrast, require Slack to reach a public endpoint you control, which means running (or renting) a server — not something a distributed desktop app can reasonably ask every user to set up. Reserve this approach for a companion backend service if your product already has one; otherwise Socket Mode is almost always the right choice for a pure Electron connector.

Rate limits, retries, and staying a good citizen

Slack's Web API enforces per-method rate limits (with Retry-After headers on 429 responses). Since a desktop app can have thousands of independent instances all talking to Slack, it's worth:

1. Using @slack/web-api's built-in rate-limit handling rather than rolling your own retry logic.

2. Batching or debouncing UI-triggered calls (e.g. don't fire a conversations.list call on every keystroke of a channel picker).

3. Caching channel/user lists locally with a short TTL, refreshing on demand rather than polling continuously.

Handling reconnection and token expiry gracefully

Two failure modes show up constantly in production Slack connectors:

1. Socket Mode disconnects — networks sleep, laptops close, Wi-Fi drops. The SocketModeClient emits disconnect and reconnecting events; surface a subtle "reconnecting to Slack…" state in the UI rather than failing silently.

2. Token revocation — a user can revoke your app's access from the Slack admin console at any time. Catch invalid_auth errors from the Web API and route the user back into the OAuth flow rather than showing a generic error.

A minimal checklist before shipping

1. OAuth and Web API calls live in the main process only; the renderer talks to Slack exclusively through IPC.

2. contextIsolation: true, nodeIntegration: false, and a narrow contextBridge API.

3. Tokens stored via keytar or safeStorage, never in plain-text config files.

4. Auth happens in the system browser via shell.openExternal, not an embedded BrowserWindow.

5. Socket Mode for real-time events unless you already run a backend that can host HTTP event subscriptions.

6. Scopes requested are the minimum your features need — resist asking for admin-level scopes for a notification feature.

Put together, this gives you a Slack connector that feels native to the desktop, keeps credentials where the OS expects them to live, and doesn't force every user to stand up infrastructure just to get a notification when someone mentions them in a channel.