Slack Api Automation

---
name: slack-api-automation
description: Automate Slack via its native Web API: bots, messages, workflows, and integrations without middleware. Use when building Slack-native automations with code you control.
category: workflow-automation
---

# Slack API Automation

## Overview

Slack's Web API (plus Events API, Socket Mode, and Block Kit) lets you build bots, post messages, manage channels, and react to events — with code you own.

Use cases: deploy notifications, alert routing, ChatOps commands, onboarding flows, standup bots, and custom integrations.

This skill uses Slack's native APIs directly — no middleware platform required.

## When to use

- Posting automated messages and alerts to Slack
- Building a Slack bot (notifications, commands, interactivity)
- Reacting to Slack events (messages, reactions, joins)
- ChatOps: triggering actions from Slack commands
- Workspace administration via API (channels, users, invites)

## Core concepts

- **Web API basics.**
  chat.postMessage, conversations.*, users.*, files.upload — REST with bearer tokens. Block Kit for rich, interactive message layouts.
- **App tokens and scopes.**
  Slack apps with granular OAuth scopes (chat:write, channels:read...). Least privilege; separate dev/prod apps. Rotate tokens.
- **Events API + Socket Mode.**
  Subscribe to events (message, reaction_added, member_joined_channel). Socket Mode avoids public webhooks during development.
- **Slash commands.**
  Custom /commands triggering your service. Great for ChatOps: /deploy, /incident, /oncall. Fast to build, obvious to use.
- **Block Kit.**
  Structured message layouts: sections, buttons, selects, modals. Interactive workflows (approvals, forms) inside Slack.
- **Rate limits.**
  Tiered rate limits per method. Handle 429s with Retry-After; batch where possible; cache channel/user lists.
- **Bots vs. user tokens.**
  Bot tokens for app actions; user tokens only when acting as a user is required. Prefer bots — auditable and scoped.
- **Workflow Builder + webhooks.**
  For simple flows, native Workflow Builder with incoming webhooks covers a lot without code. Code when logic gets complex.

## Practical workflow

1. **Define the automation.**
   What event, what action, what message? Sketch the Block Kit layout for anything user-facing.
2. **Create the Slack app.**
   App manifest or dashboard: scopes (minimal), events subscribed, slash commands, interactivity URLs. Dev app first.
3. **Authenticate securely.**
   OAuth flow for distribution; bot tokens in secrets manager. Never hardcode tokens; never commit them.
4. **Build the handler.**
   Receive events/commands, validate signatures (signing secret — always verify), execute logic, respond with Block Kit.
5. **Handle rate limits.**
   Respect Retry-After on 429s; queue outbound messages; cache lookups. Test under burst conditions.
6. **Test in dev workspace.**
   Full flow in a test workspace/channel before touching production channels. Especially for broadcast-y automations.
7. **Deploy and monitor.**
   Hosted service with logging; alert on handler errors; Slack-side: monitor app metrics for failures.
8. **Document.**
   README: what it does, commands/events, scopes needed, owner, how to disable. Bots without docs become mysteries.

## Common pitfalls

- **Missing signature verification.**
  Accepting Events API payloads without verifying the signing secret. Spoofable endpoints are a security hole.
- **Overbroad scopes.**
  Requesting admin scopes 'just in case.' Least privilege; audit scopes yearly.
- **No rate limit handling.**
  Burst-posting into 429s and dropping messages. Queues + Retry-After respect are mandatory.
- **Hardcoded tokens.**
  Tokens in code, repos, or chat. Secrets manager + rotation; treat tokens like passwords.
- **Spammy bots.**
  Bots posting to #general for every minor event. Route to specific channels; respect notification norms; provide mute/opt-out.
- **Untested in prod-like.**
  Dev-tested only, then unleashed on 500-person channels. Test workspace first, always.
- **Ignoring interactivity timeouts.**
  Slash commands must respond in 3s (ack) or use response_url. Design for the timeout.
- **No off switch.**
  Bot misbehaving with no quick disable. Document how to disable; keep app admin access handy.