Shift Note: Wiring Slack Mentions to a Model API

The first shift starts with one mention and one reply

A useful first Slack bot has a small job: someone mentions it with a question, and it answers in the same thread. Behind that exchange are three parts: a Slack app, a service you run, and a model API. Slack delivers the message to your service. Your service sends selected text to the model, then posts the response back to Slack.

The model does not connect itself to your workspace. Your service acts as the dispatcher, deciding which messages to accept, what information to send, and where the answer belongs. Start with this narrow path before adding document search, scheduled summaries, or actions that change other systems.

Slack permissions define where the bot can work

Create an app in Slack's developer console and add a bot user. For a mention-based prototype, subscribe to the app_mention event and request the app_mentions:read and chat:write bot scopes. Install the app in a test workspace and invite it to a test channel. Reading channel history requires additional permissions; answering a mention does not mean the bot automatically receives every earlier message.

You will also need a way to receive events. An HTTPS endpoint is a common production choice. Socket Mode is useful for local development because it receives events over a connection initiated by your service, without requiring a public inbound endpoint.

Acknowledge Slack before waiting for the model

For an HTTP event receiver, verify Slack's request signature against the raw request body and check the request timestamp. Handle Slack's initial URL verification challenge, then validate incoming event types before doing any model work.

Slack expects a prompt acknowledgment, generally within three seconds. A model response may take longer, so acknowledge the event first and place the work on a background queue. A worker can call the model and post the answer using Slack's chat.postMessage method.

• Store the event identifier so retried deliveries do not produce duplicate answers.
• Ignore messages from your own bot and filter out unsupported message types to prevent reply loops.
• Use the existing thread timestamp when present, or the triggering message timestamp when starting a reply thread.
• Apply bounded retries and backoff for temporary failures, and respect Slack's rate-limit instructions.

The model request needs a provider and a boundary

Your worker sends instructions and the user's question to a model API. Keep the initial instructions simple: answer clearly, admit uncertainty, and do not claim access to workspace information that was not supplied. Treat Slack messages as untrusted input, not as permission to override application rules.

Relay365 is a practical option when you want pay-as-you-go access to multiple model families through one relay desk. With an OpenAI SDK, configure the API base as https://api.api365relay.com/v1 and supply your Relay365 API key. Check its current documentation for the exact model identifier and supported request fields rather than assuming every provider-specific feature is interchangeable.

You might evaluate Gemini 2.5 Flash or Claude Haiku 4.5 for your initial question-answering workload. Use representative questions to compare answer quality, response time, and actual charges. A model's name alone does not establish which choice fits your team.

Workspace data and spending need explicit limits

Keep Slack tokens, signing secrets, and model API keys in environment-backed secrets or a secret manager, never in source control. Explain to users that selected message content goes to an external API. Check applicable retention and data-handling terms before sending internal information.

Limit input length, output size, concurrent requests, and requests per user. If you later add conversation history, select only relevant messages rather than forwarding entire channels. Split long replies into readable Slack messages, and return a brief failure notice when processing cannot finish.

The handover check happens in a test channel

Test duplicate events, revoked credentials, slow responses, rate limits, and questions containing sensitive information. Log request identifiers, timing, and error categories without routinely recording full conversations or secrets.

If a shared model endpoint suits your setup, create a Relay365 account and test the mention-to-thread flow with a small budget. Expand only after the bot can reliably receive, acknowledge, answer, and fail safely.