🚨 Slack API Error Guide: 'no_permission' and 'restricted_action' Blocked by Policy

Overview

The no_permission and restricted_action errors mean the token authenticated, but the actor is not allowed to perform this specific action. no_permission usually signals the token lacks the authority (scope or role) for the operation. restricted_action signals a workspace or org policy actively blocks it — for example, admins have disabled channel creation, archiving, or invites for non-admins. The credential is valid and the right type; the action itself is denied by permission or policy.

You will see one of these in the JSON body:

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

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

It occurs on state-changing methods — conversations.create, conversations.archive, conversations.invite, admin.* — where authority and policy are enforced.

Symptoms

• A state-changing call returns no_permission or restricted_action.
• Read calls succeed but writes/admin actions fail.
• The same action works for an admin user but not the bot or a regular user.
• The failure appeared after a workspace policy change.

curl -s -X POST https://slack.com/api/conversations.archive \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789"}'

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

Common Root Causes

1. Workspace policy disables the action for non-admins

Admins can restrict who may create, archive, or rename channels. A bot or regular user hitting a restricted action gets restricted_action.

curl -s -X POST https://slack.com/api/conversations.create \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"new-project"}'

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

An admin must relax the policy or perform the action.

2. Missing the management scope for the operation

no_permission often accompanies a missing management scope such as channels:manage.

curl -s "https://slack.com/api/apps.permissions.scopes.list" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

{
    "ok": true,
    "scopes": {
        "bot": ["chat:write", "channels:read"]
    }
}

Without channels:manage, channel create/archive is denied.

3. The bot is not the owner of the object

Some actions require ownership — e.g. only the message author can delete it with a bot token. Acting on another’s object yields no_permission (or cant_delete_message).

curl -s -X POST https://slack.com/api/chat.delete \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789","ts":"1718900000.000300"}'

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

The bot can only delete messages it posted.

4. Inviting users is admin-restricted

If the workspace restricts who can invite members to channels, conversations.invite returns restricted_action.

curl -s -X POST https://slack.com/api/conversations.invite \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789","users":"U0AAAAAAA"}'

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

5. An admin.* method called without admin role

admin.* methods require both the admin.* scope and a user with the admin/owner role on an org-level install. A non-admin actor is denied.

curl -s -X POST https://slack.com/api/admin.conversations.archive \
  -H "Authorization: Bearer $SLACK_USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel_id":"C0123456789"}'

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

6. Enterprise Grid policy blocks the action

On Grid, org-level policies (managed channels, name standards) can forbid an action regardless of workspace settings.

curl -s -X POST https://slack.com/api/conversations.rename \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789","name":"renamed"}'

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

Diagnostic Workflow

Step 1: Separate no_permission from restricted_action

curl -s -X POST https://slack.com/api/conversations.archive \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789"}'

no_permission points at scope/role/ownership; restricted_action points at an admin/org policy. The fixes differ.

Step 2: Verify the token carries the management scope

curl -s "https://slack.com/api/apps.permissions.scopes.list" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

Confirm scopes like channels:manage, groups:write, or the relevant admin.* scope are present.

Step 3: Confirm the actor’s role

curl -s "https://slack.com/api/auth.test" -H "Authorization: Bearer $SLACK_USER_TOKEN"
curl -s "https://slack.com/api/users.info?user=U0REALUSER" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" | grep -E 'is_admin|is_owner'

"is_admin": false,
"is_owner": false,

A non-admin actor cannot perform admin-restricted or admin.* actions.

Step 4: Check ownership for object-scoped actions

For chat.delete/chat.update, confirm the bot authored the target message — bots can only modify their own messages.

Step 5: Adjust scope/role/policy and retry

After adding the scope, elevating the actor, or having an admin relax the policy:

curl -s -X POST https://slack.com/api/conversations.archive \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789"}'

{
    "ok": true
}

Example Root Cause Analysis

A cleanup job archives stale channels nightly and now fails on every channel with restricted_action, though it worked last month. The token has the management scope:

curl -s "https://slack.com/api/apps.permissions.scopes.list" -H "Authorization: Bearer $SLACK_BOT_TOKEN"

{"ok": true, "scopes": {"bot": ["channels:read", "channels:manage"]}}

Scope is present, so this is not no_permission. The error is restricted_action, which means policy — not authority — is blocking it:

curl -s -X POST https://slack.com/api/conversations.archive \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789"}'

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

A workspace admin recently turned on “Only admins can archive channels.” The bot is not an admin, so the policy blocks it.

Fix: an admin either grants the workspace setting to allow apps to archive, or the job is switched to an admin-authorized admin.conversations.archive call on the org install. After the admin relaxes the setting, the nightly archive succeeds again.

Prevention Best Practices

• Distinguish no_permission (fix with scope/role/ownership) from restricted_action (fix with an admin policy change) in your error handling.
• Confirm management scopes (channels:manage, groups:write, relevant admin.*) are granted before relying on state-changing calls.
• Remember bots can only modify or delete their own messages; design flows around ownership rather than fighting no_permission.
• Document which workspace/org policies (channel creation, archiving, invites) your integration depends on, so a policy toggle does not silently break it.
• For org-wide actions, install at the org level and use an admin-authorized token rather than expecting a workspace bot to satisfy admin.* methods.
• For ad-hoc triage, the free incident assistant can tell a missing-scope denial apart from a policy-driven block. See more in Slack guides.

Quick Command Reference

# Which error is it?
curl -s -X POST https://slack.com/api/conversations.archive \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789"}'

# Does the token have the management scope?
curl -s "https://slack.com/api/apps.permissions.scopes.list" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN"

# Is the acting user an admin/owner?
curl -s "https://slack.com/api/users.info?user=U0REALUSER" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" | grep -E 'is_admin|is_owner'

# Retry after fixing scope/role/policy
curl -s -X POST https://slack.com/api/conversations.invite \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789","users":"U0AAAAAAA"}'

Conclusion

no_permission and restricted_action both deny an action the token authenticated for — but for different reasons. The usual root causes:

1. A workspace policy disabling the action for non-admins (restricted_action).
2. A missing management scope like channels:manage (no_permission).
3. Acting on an object the bot does not own (e.g. another user’s message).
4. Admin-restricted member invites blocked by policy.
5. An admin.* method called without the admin role or org install.
6. An Enterprise Grid org policy forbidding the action outright.

Read the exact error to choose the fix — add a scope or elevate the actor for no_permission, or have an admin relax the policy for restricted_action — then retry the state-changing call.