🚨 Slack API Error Guide: 'account_inactive' App or User Deactivated

Overview

The account_inactive error means the token authenticates against a user or app that is no longer active in the workspace. The most common case is that the app was uninstalled or its authorization removed, so the bot user backing the token is now inactive. For user (xoxp-) tokens, it means the human whose authorization minted the token was deactivated (deprovisioned). It is distinct from invalid_auth (malformed token) and token_revoked (credential killed): here the credential maps to a real but deactivated identity.

You will see this in the JSON body of any Web API call:

{
    "ok": false,
    "error": "account_inactive"
}

It occurs at the authentication layer, so auth.test reproduces it directly.

Symptoms

• Every API call returns account_inactive, not just one endpoint.
• The failure began after an app was uninstalled or a user was deactivated.
• A user token fails right after that person left the company / was deprovisioned.
• The workspace itself may have been downgraded, suspended, or deleted.

curl -s "https://slack.com/api/auth.test" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

{
    "ok": false,
    "error": "account_inactive"
}

Common Root Causes

1. The app was uninstalled, deactivating its bot user

When an app is removed, its bot user becomes inactive and the bot token returns account_inactive.

curl -s "https://slack.com/api/auth.test" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

{
    "ok": false,
    "error": "account_inactive"
}

Reinstall the app to reactivate the bot and mint a working token.

2. The user behind a user token was deactivated

A xoxp- token is tied to a human. When that account is deactivated/deprovisioned (offboarding), the token goes inactive.

curl -s "https://slack.com/api/auth.test" \
  -H "Authorization: Bearer $SLACK_USER_TOKEN"

{
    "ok": false,
    "error": "account_inactive"
}

Re-authorize the app as an active user to obtain a new user token.

3. The bot was disabled by an admin

An admin can disable an app/bot without a full uninstall; the bot user is then inactive.

curl -s "https://slack.com/api/bots.info?bot=B0BOTID001" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

{
    "ok": false,
    "error": "account_inactive"
}

Have an admin re-enable the app in the workspace’s app management.

4. The workspace was deleted or suspended

If the workspace no longer exists or is suspended for billing, all its tokens report inactive accounts.

curl -s "https://slack.com/api/auth.test" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

{
    "ok": false,
    "error": "account_inactive"
}

Confirm the workspace status with an admin before troubleshooting the token.

5. Using a token for a workspace the app was removed from

For an app installed to multiple workspaces, removing it from one workspace makes that workspace’s token inactive while others keep working.

curl -s "https://slack.com/api/auth.test" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN_TEAM_B"

{
    "ok": false,
    "error": "account_inactive"
}

Re-pull only the affected workspace’s token after reinstalling there.

6. Acting as a service account that was offboarded

If your integration used a real employee’s user token rather than a dedicated bot, offboarding that employee silently breaks the integration.

curl -s "https://slack.com/api/auth.test" \
  -H "Authorization: Bearer $SLACK_USER_TOKEN"

{
    "ok": false,
    "error": "account_inactive"
}

Migrate the integration to a bot token to avoid future offboarding breakage.

Diagnostic Workflow

Step 1: Reproduce with auth.test

curl -s "https://slack.com/api/auth.test" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

account_inactive here confirms the token maps to a deactivated identity rather than being malformed.

Step 2: Determine whether it is a bot or user token

printf '%s' "$SLACK_TOKEN" | cut -c1-5

xoxb-

xoxb- points at an uninstalled/disabled app; xoxp- points at a deactivated human.

Step 3: Check the app’s install state

In the app’s OAuth & Permissions / Manage Distribution pages, confirm whether the app is still installed to the workspace. A missing install explains a xoxb- failure.

Step 4: Check the user / workspace status (for user tokens)

For an xoxp- token, ask an admin whether the underlying user is still active, and whether the workspace itself is suspended or deleted.

Step 5: Reinstall or re-authorize, then verify

# After reinstalling the app or re-authorizing as an active user:
curl -s "https://slack.com/api/auth.test" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

{
    "ok": true,
    "team": "ACME Prod",
    "user_id": "U0BOTBOT01"
}

Example Root Cause Analysis

A reporting bot that has run for a year suddenly fails every call with account_inactive. The token format looks normal:

printf '%s' "$SLACK_TOKEN" | cut -c1-5

xoxp-

It is a user token, not a bot token. The integration was originally wired up with an engineer’s personal authorization. That engineer left the company last week and was deprovisioned, deactivating the account the token represents:

curl -s "https://slack.com/api/auth.test" -H "Authorization: Bearer $SLACK_TOKEN"

{"ok": false, "error": "account_inactive"}

Fix: create a dedicated Slack app with a bot user, grant it the needed bot scopes, install it, and switch the integration to the xoxb- bot token so no human’s offboarding can break it again:

curl -s "https://slack.com/api/auth.test" -H "Authorization: Bearer $SLACK_BOT_TOKEN"

{"ok": true, "team": "ACME Prod", "user_id": "U0NEWBOT99"}

Prevention Best Practices

• Back integrations with a dedicated bot token, never an individual employee’s user token, so offboarding cannot silently break them.
• Run auth.test as a startup and periodic health check so an uninstalled app or deactivated account surfaces immediately.
• Track app installs per workspace; for multi-workspace apps, monitor each token independently since one removal does not affect the others.
• Document which human authorized any unavoidable user token, and rotate ownership before that person offboards.
• Alert on account_inactive distinctly from token_revoked — it usually points at an identity/install change rather than a credential rotation.
• For ad-hoc triage, the free incident assistant can separate a deactivated-user failure from an uninstalled-app one. See more in Slack guides.

Quick Command Reference

# Reproduce the failure
curl -s "https://slack.com/api/auth.test" -H "Authorization: Bearer $SLACK_BOT_TOKEN"

# Bot token or user token?
printf '%s' "$SLACK_TOKEN" | cut -c1-5

# Inspect the bot user (if you have its ID)
curl -s "https://slack.com/api/bots.info?bot=B0BOTID001" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

# Verify a reinstalled / re-authorized token
curl -s "https://slack.com/api/auth.test" -H "Authorization: Bearer $SLACK_BOT_TOKEN"

Conclusion

account_inactive means the token maps to a real but deactivated user or app. The usual root causes:

1. The app was uninstalled, deactivating its bot user.
2. The human behind a user token was deactivated/deprovisioned.
3. An admin disabled the app without a full uninstall.
4. The workspace was deleted or suspended.
5. The app was removed from one workspace of a multi-workspace install.
6. The integration relied on an offboarded employee’s user token.

Reproduce with auth.test, check the token type, and confirm the app’s install state or the user’s status — then reinstall or re-authorize, and migrate fragile user-token integrations to a dedicated bot.