Updatesapi-slack

Slack Web API Update: Admin.Users.Session.Reset, Apps.Permissions.Request Breaking Changes

9d979d9278953f1e8b4a0385Verified February 22, 2026

```mdx

Quick Summary

This release introduces 100 breaking changes across 53 Slack Web API endpoints, with every single change classified as breaking — there are no deprecations, additions, or informational updates to soften the impact. The dominant pattern is the formalization of previously optional parameters: token (in headers or query strings), resource identifiers like channel, user_id, and ts, and action-specific fields like scopes, trigger_id, and scheduled_message_id have all been promoted to required status. If your integration passes these values inconsistently or relies on server-side defaults, requests will begin failing at the API layer. The breadth of affected endpoints — spanning authentication, messaging, reactions, user groups, DND controls, and admin tooling — means virtually any active Slack app will need to audit its request construction before deploying against this spec version.

---

Editor's Note: We consider this a significant structural shift rather than routine maintenance — the scale of simultaneous breaking changes across this many endpoints is unusual and suggests a deliberate API hardening effort, likely tied to Slack's ongoing push to enforce explicit authorization on every call. We've been tracking a broader trend of Slack tightening token scoping and parameter validation over recent spec revisions, and this commit accelerates that direction considerably. Our practical tip: prioritize auditing any wrapper or SDK layer that auto-constructs requests, since missing a token header on even one high-traffic endpoint like /chat.postMessage will cause silent failures in production.

---

Changes by Severity

#### 🔴 Immediate Action Required

Token enforcement is now explicit across the entire API surface.

The token parameter — previously implicit or optional in many endpoints — is now formally required, either as a header parameter or a query parameter depending on the endpoint. This affects nearly every resource in this diff.

  • /auth.test now requires token as a header parameter. This endpoint is commonly used for connection validation; any health-check logic that omits the header will now receive an error response.
  • /auth.revoke requires token as a query parameter. Revocation flows that construct the URL without an explicit token will fail.
  • /bots.info requires token as a query parameter.
  • /emoji.list requires token as a query parameter.
  • /migration.exchange requires token as a query parameter.
  • /admin.users.session.reset — two new required parameters added.

    Both user_id (as formData) and token (as header) are newly required. This endpoint previously had a more permissive signature; admin tooling that calls it without explicitly supplying both fields will now fail.

    /chat.postMessagechannel and token are now required.

    The channel field in formData and token in the request header are both required. Given the volume of traffic this endpoint typically handles, any integration that constructs post payloads without these fields explicitly set should be treated as broken immediately.

    /chat.deleteScheduledMessage — three new required fields.

    channel and scheduled_message_id (both formData) and token (header) are newly required parameters. Scheduled message management flows need to be updated to supply all three.

    /chat.postEphemeralchannel, user, and token are now required.

    All three were promoted to required status. Ephemeral message delivery that omits the target user field will fail, which is particularly relevant for bot-driven notification systems.

    /chat.update and /chat.unfurlchannel, ts, and token are now required.

    Both endpoints require channel and ts in formData and token in the header. Message update and unfurl workflows that don't explicitly pass the timestamp will break.

    /chat.getPermalinkchannel, message_ts, and token are now required query parameters.

    Permalink generation that relies on partial query strings will fail.

    /apps.permissions.request and /apps.permissions.users.request — multiple required query parameters.

    scopes, token, and trigger_id are all required for /apps.permissions.request. /apps.permissions.users.request additionally requires user. Permission request flows that don't supply a trigger_id — which must come from a valid user interaction — will be rejected.

    /apps.permissions.resources.list, /apps.permissions.scopes.list, /apps.permissions.users.listtoken is now required.

    All three listing endpoints require an explicit token query parameter.

    /channels.setPurpose, /channels.setTopic, /channels.unarchive — channel identifiers and tokens are now required.

    channel in formData and token in the header are required for all three. /channels.setPurpose additionally requires purpose; /channels.setTopic requires topic.

    /dialog.opentoken is now required as a header parameter.

    Dialog-triggering flows that don't pass an explicit authorization header will fail.

    /dnd.endDnd, /dnd.endSnooze, /dnd.setSnooze — token enforcement applied.

    DND management endpoints now require explicit token headers. /dnd.setSnooze also requires num_minutes in formData.

    /groups.kick, /groups.leavechannel and token are now required.

    Private channel management calls must include both fields. /groups.kick additionally requires user in formData.

    /im.close, /im.mark, /mpim.close — channel and token required.

    Direct message and multi-party IM session management now enforces explicit channel and token fields.

    /pins.addchannel and token are now required.

    Pin management calls that omit the channel identifier will fail.

    /reactions.add, /reactions.removename, channel (or target), and token are now required.

    Reaction management endpoints enforce explicit target and authorization fields. /reactions.get and /reactions.list require token as a query parameter.

    /rtm.connecttoken is now required as a query parameter.

    RTM connection bootstrapping must supply an explicit token; any reconnection logic that omits it will fail to establish a session.

    /search.messagesquery and token are now required query parameters.

    Search integrations that don't pass an explicit query string will receive errors.

    /stars.addtoken is now required as a header parameter.

    Star management calls must include explicit authorization.

    /team.accessLogs, /team.billableInfo, /team.info, /team.integrationLogs, /team.profile.gettoken is now required.

    All team-scoped endpoints now enforce explicit token parameters. Workspace analytics or admin dashboards that call these endpoints without explicit tokens will fail.

    */usergroups. endpoints — token and resource identifiers are now required.**

    /usergroups.create, /usergroups.disable, /usergroups.enable, /usergroups.list, /usergroups.update, /usergroups.users.list, and /usergroups.users.update all require explicit token headers and, where applicable, usergroup identifiers and users lists.

    /users.deletePhoto, /users.getPresence, /users.info, /users.setActive, /users.setPresence — token and user identifiers enforced.

    User profile management endpoints now require explicit authorization and, in several cases, explicit user identifiers.

    ---

    Migration Playbook

    1. Audit your token passing strategy across all API calls.

    The single most impactful change in this diff is the universal enforcement of token. Determine whether each endpoint in your integration expects token as a header or a query parameter — the pattern is not uniform. For example, /auth.test and /chat.postMessage expect it as a header:

    ```http

    POST /api/chat.postMessage

    Authorization: Bearer xoxb-your-token

    Content-Type: application/x-www-form-urlencoded

    channel=C1234567890&text=Hello

    ```

    While /auth.revoke and /bots.info expect it as a query parameter:

    ```http

    GET /api/auth.revoke?token=xoxb-your-token

    ```

    Cross-reference the updated spec at the commit linked in References to confirm the expected location for each endpoint you use.

    2. Update /admin.users.session.reset call sites to include user_id and token.

    Both are newly required. A corrected request looks like:

    ```http

    POST /api/admin.users.session.reset

    token: xoxb-your-admin-token

    Content-Type: application/x-www-form-urlencoded

    user_id=U1234567890

    ```

    Verify that your admin tooling constructs both fields before sending.

    3. Fix /chat.deleteScheduledMessage to supply all three required fields.

    channel, scheduled_message_id, and token are all newly required. Update your scheduled message deletion logic:

    ```http

    POST /api/chat.deleteScheduledMessage

    token: xoxb-your-token

    Content-Type: application/x-www-form-urlencoded

    channel=C1234567890&scheduled_message_id=Q1234567890

    ```

    If your system stores scheduled message IDs at creation time, verify that storage is reliable — you now have no fallback if the ID is missing.

    4. Update permission request flows to include trigger_id.

    /apps.permissions.request and /apps.permissions.users.request now require trigger_id, which must originate from a valid user interaction event (button click, slash command, etc.). Ensure your permission request logic is only invoked within the valid trigger window (typically 3 seconds from the user action):

    ```

    GET /api/apps.permissions.request

    ?token=xoxb-your-token

    &scopes=channels:read,chat:write

    &trigger_id=12345.98765.abcd2358fdea

    ```

    Flows that attempt to request permissions outside of an interaction context will not be able to supply a valid trigger_id and will fail.

    5. *Review all channels., groups., im., and mpim. call sites for explicit channel fields.*

    Parameters like channel in formData were previously optional in several of these endpoints. Locate every call to /channels.setPurpose, /channels.setTopic, /channels.unarchive, /groups.kick, /groups.leave, /im.close, /im.mark, /mpim.close, and confirm the channel identifier is always explicitly set — not assumed from context or session state.

    6. Update RTM reconnection logic to pass token explicitly.

    /rtm.connect now requires token as a query parameter. If your RTM client uses a reconnection loop, ensure the token is re-supplied on each connection attempt:

    ```http

    GET /api/rtm.connect?token=xoxb-your-token

    ```

    7. Patch usergroup management endpoints to include token and required identifiers.

    For endpoints like /usergroups.update and /usergroups.users.update, both token (header) and the usergroup identifier are required. A corrected update call:

    ```http

    POST /api/usergroups.update

    token: xoxb-your-token

    Content-Type: application/x-www-form-urlencoded

    usergroup=S1234567890&name=Updated+Group+Name

    ```

    8. Run integration tests against the updated spec before deploying.

    Use the spec diff (linked in References) to generate a checklist of every endpoint your application calls. For each one, confirm that all newly required parameters are present in your test fixtures. Consider adding a contract test layer that validates outgoing requests against the OpenAPI spec to catch missing required fields before they reach production.

    ---

    Verification Checklist

  • ☐ Confirmed that token is passed as a header for all endpoints that require it there (e.g., /auth.test, /chat.postMessage, /chat.postEphemeral, /chat.update, /chat.unfurl, /channels.setPurpose, /channels.setTopic, /channels.unarchive, /dialog.open, /stars.add, and all usergroups.* endpoints)
  • ☐ Confirmed that token is passed as a query parameter for all endpoints that require it there (e.g., /auth.revoke, /bots.info, /emoji.list, /rtm.connect, /search.messages, /reactions.get, /reactions.list, and all apps.permissions.* endpoints)
  • ☐ Verified that /admin.users.session.reset calls include both user_id in formData and token in the header
  • ☐ Verified that /chat.deleteScheduledMessage calls include channel, scheduled_message_id, and token
  • ☐ Verified that /apps.permissions.request and /apps.permissions.users.request calls include scopes, token, trigger_id, and (for the latter) user
  • ☐ Confirmed that all channels. and groups. endpoints receive explicit channel identifiers in formData
  • ☐ Confirmed that /chat.update and /chat.unfurl calls include ts in formData
  • ☐ Confirmed that /chat.getPermalink calls include channel and message_ts as query parameters
  • ☐ Verified that RTM reconnection logic supplies token as a query parameter on every /rtm.connect call
  • ☐ Ran integration or contract tests against the updated spec for every affected endpoint used in your application
  • ☐ Reviewed any SDK or HTTP client wrapper layers that auto-construct requests to confirm they propagate all newly required fields
  • ☐ Confirmed that DND endpoints (/dnd.endDnd, /dnd.endSnooze, /dnd.setSnooze) include explicit token headers, and that /dnd.setSnooze includes num_minutes
  • ---

    References

  • [Commit 3f1e8b4a0385 — slackapi/slack-api-specs](https://github.com/slackapi/slack-api-specs/commit/3f1e8b4a03855cb29cffbfcaf60195e5867780ea) — Last verified: 2026-02-22
  • [Slack Web API Spec Diff: 9d979d9 → 3f1e8b4](https://github.com/slackapi/slack-api-specs/compare/9d979d927895de5cf18a93f4b81a96a871e543db...3f1e8b4a03855cb29cffbfcaf60195e5867780ea) — Last verified: 2026-02-22
  • ```

    📎 Sources