Slack App Privacy Policy: What the App Directory Requires and How to Write One

Q: What data does a Slack app collect through OAuth?

At minimum, the OAuth flow returns a team.id, team.name, authed_user.id, and an access_token. Beyond that, each requested scope opens access to additional data: users:read exposes user profiles, channels:history exposes full message content in public channels, and files:read exposes shared file metadata and download links.

Q: How do I add a privacy policy URL to my Slack app?

Go to api.slack.com/apps, select your app, navigate to Manage Distribution, and enter the URL in the Privacy Policy URL field. The URL must load over HTTPS without requiring authentication. It appears to workspace admins during the installation flow and on your App Directory listing.

Q: Does my Slack app's privacy policy need to cover the Events API?

If your app subscribes to any event types like message.channels, message.groups, message.im, app_mention, or file_shared, the policy must disclose that the app receives those event payloads. Each event delivers the sender's user ID, channel ID, and the event-specific data. Even if the data is processed in memory and not stored, that processing must be disclosed.

Published October 2, 2026

The Slack App Directory requires every publicly distributed app to provide a privacy policy URL before it can be submitted for review. The privacy policy field is mandatory in the submission form at api.slack.com/apps -- without a valid URL, the review process cannot start. This applies to every distributed app, whether it uses OAuth, the Events API, slash commands, or interactive components like modals and buttons.

This guide walks through what Slack's app review actually checks, what data a Slack app receives through OAuth scopes and the Events API, how to map your requested scopes to privacy disclosures, GDPR obligations and data retention, and a copy-ready sample policy you can adapt for your own app. If you want a finished policy without writing one from scratch, use the free privacy policy generator and get a hosted URL you can paste straight into your app settings.

What the Slack App Directory Review Requires

Slack's app review team evaluates privacy policies as part of the submission process. On the app configuration page at api.slack.com/apps, the Privacy Policy URL field sits alongside the app description, support URL, and redirect URLs under the "Manage Distribution" section. Apps that leave this field blank cannot be submitted to the directory.

The review looks for specifics. Slack's Developer Policy requires that apps clearly disclose what information they collect, how they use and share it, and what choices users have. A generic boilerplate policy that never mentions Slack-specific data types -- OAuth tokens, workspace data, message content received through the Events API -- gets flagged. The policy has to match what the app actually does with the scopes it requests.

Internal apps distributed within a single workspace do not go through the App Directory review and do not need a public privacy policy URL from Slack's side. But any app submitted to the public directory must have one, and it must be hosted at a URL that loads over HTTPS without authentication. The same pattern applies elsewhere: Discord requires a privacy policy URL in the Developer Portal before bot verification, and Google enforces one for every Chrome Web Store extension listing.

What Data a Slack App Actually Collects

What your app receives depends on which API surfaces it uses. The gap between what developers think their app collects and what actually flows through their endpoints is where most privacy policy gaps appear.

OAuth tokens and identity. When a user or workspace admin installs your app, the OAuth 2.0 flow (oauth.v2.access) returns a bot token or user token scoped to the permissions the installer approved. The response payload includes team.id, team.name, authed_user.id, and the access_token itself. For apps requesting user tokens, authed_user.access_token grants access to data on behalf of that specific user -- the token is a credential that represents their identity and persists until revoked.
User profiles. Apps with the users:read scope can call users.info and users.list to retrieve display names, real names, status text, time zones, and profile images. Adding the users:read.email scope exposes email addresses. These are personal data under GDPR regardless of whether you persist them to a database.
Channel and conversation metadata. The channels:read scope exposes the names, topics, purposes, and member counts of public channels. groups:read does the same for private channels the app has been invited to. conversations.list and conversations.info are the Web API methods that return this data.
Message content via the Events API. Apps subscribed to the message.channels, message.groups, message.im, or message.mpim event types receive message payloads in real time. Each event payload includes the sender's user ID, text, ts (timestamp), channel, and any files, blocks, or attachments. If your app subscribes to these events, it is processing message content -- disclose that in the policy even if the data never hits a database.
Files. The files:read scope lets your app call files.info and files.list to retrieve file metadata and download shared files. File objects include the uploader's user ID, name, filetype, size, and a url_private download link that requires the bot token to access.
Slash commands and interactive payloads. When a user invokes a slash command, Slack sends a POST request to your configured endpoint with user_id, user_name, team_id, channel_id, channel_name, and the command text. Interactive components -- buttons, overflow menus, date pickers, modals submitted via views.submit -- send similar payloads including a trigger_id and the user's action or form input data.

The takeaway: even a minimal app that stores nothing still processes user IDs, workspace identifiers, and command text in memory on every request. Writing a privacy policy for any app starts with auditing what you actually receive, not just what you save.

OAuth Scopes as the Disclosure Map

Slack's permission model is granular enough to serve as the skeleton of your privacy policy's data-collection section. Each scope your app requests maps directly to a category of data you must disclose. Review your app's scope list at api.slack.com/apps under "OAuth & Permissions" -- every checked scope is a disclosure obligation.

Scope	Data accessed	Disclose as
`users:read`	Display name, real name, status, time zone, profile image	User profile information
`users:read.email`	Email addresses of workspace members	Email addresses
`channels:read`	Public channel names, topics, member counts	Workspace channel metadata
`channels:history`	Full message text, files, and reactions in public channels	Message content in public channels
`groups:history`	Full message text, files, and reactions in private channels	Message content in private channels
`im:history`	Direct message text and attachments	Direct message content
`files:read`	File metadata and download URLs	Shared files and file metadata
`chat:write`	Ability to post messages (write-only, not read)	Outbound messages posted by the app
`reactions:read`	Emoji reactions on messages	Reaction data and associated messages
`team:read`	Workspace name, email domain, icon	Workspace-level metadata

If your app requests a scope, the policy must name the data that scope grants access to. This table covers the most common bot token scopes; user token scopes like search:read or stars:read carry their own disclosure requirements. The full list of available scopes is documented in the Slack API scopes reference.

Most Slack workspaces include users in the EU or UK, putting GDPR in play regardless of where the developer is based. The two legal bases that apply to most Slack apps:

Legitimate interest (Article 6(1)(f)) -- processing workspace data to deliver the app's core function. A summarization app that reads channel history, a standup bot that posts scheduled prompts, a moderation tool that scans messages for policy violations -- each processes data the user expects when the app is installed.
Consent (Article 6(1)(a)) -- any processing beyond the app's stated purpose: analytics on message patterns, sharing message content with a third-party AI service, using workspace data for product improvement or model training. A workspace admin installing the app is not GDPR consent from individual users -- if your basis is consent, it must come from each user directly.

For retention, state concrete periods. "We retain message data for 30 days to provide search functionality, then delete it" is a meaningful disclosure. "We retain data as long as necessary" is not. Slack's Developer Policy requires that apps delete data obtained through the API when the app_uninstalled or tokens_revoked event fires, unless the data has been aggregated and fully anonymized. Subscribe to both events and build the deletion handler before you ship.

Sub-processors must be named. If your app runs on AWS or GCP, stores data in a managed database like Supabase or PlanetScale, calls the OpenAI API with message content, or uses Sentry for error tracking, each of those is a sub-processor receiving workspace data. List them by name and state what data each receives.

Sample Slack App Privacy Policy

A template for an app called "[Your App Name]." Copy it, fill in the bracketed fields, and remove any section that does not apply.

Sample Privacy Policy — ready to copy

Privacy Policy for [Your App Name]

Last updated: [Date]

1. Introduction

[Your Name / Organization] ("we," "us," or "our") operates the [Your App Name] Slack app ("the App"). This policy explains what data the App collects through the Slack API, why it collects it, who else receives it, how long it is kept, and your rights regarding that data.

2. Data We Collect

The App requests the following OAuth scopes and processes the data they grant access to:

Workspace identity — team ID, team name, and installing user ID, received during the OAuth installation flow.
User profiles [if users:read is requested] — display name, real name, time zone, status, and profile image via the users.info and users.list Web API methods. [Add: and email address, if users:read.email is requested.]
Channel metadata [if channels:read or groups:read is requested] — channel names, topics, purposes, and member counts.
Message content [if channels:history, groups:history, im:history, or Events API subscriptions are used] — message text, sender user ID, timestamp, attached files, reactions, and threaded replies. [State whether processed in memory only or stored, and for how long.]
Files [if files:read is requested] — file metadata (name, type, size, uploader) and file content.
Slash command and interaction data — user ID, channel ID, and input text sent when a user invokes a slash command or interacts with a button, menu, or modal.

3. How We Use This Data

To operate the App's features as described in its Slack App Directory listing: [describe core function, e.g., summarize channel discussions / run daily standups / moderate messages]. We do not use workspace data for advertising, sell it to third parties, or use it to train machine learning models.

4. Third-Party Services

[Hosting provider, e.g., AWS / Vercel / Railway] — runs the App's backend. [Database provider, e.g., Supabase / PlanetScale] — stores [specify what is stored]. [AI provider, if applicable, e.g., OpenAI] — processes [message content / query text] to [describe purpose]. [Error tracking, e.g., Sentry] — receives error logs that may include request metadata. No other third party receives workspace data.

5. Data Retention

[Message content / processed data] is deleted within [number] days. Workspace configuration and user preferences are kept while the App is installed and deleted within [number] days after the App is uninstalled (triggered by the app_uninstalled event). OAuth tokens are revoked and deleted immediately upon uninstallation. Error logs are retained for [number] days.

6. Your Rights

You may request a copy of your data, ask us to correct or delete it, or object to its processing by contacting [your-email@example.com]. We respond within 30 days. If you are in the EU or UK, you have rights under GDPR including the right to lodge a complaint with your local data protection authority. If you are in California, you have rights under CCPA including the right to know what data we hold and to request its deletion. We do not sell personal information.

7. Children

The App is not directed at users under 16. We do not knowingly collect data from children and will delete it promptly if we become aware of it.

8. Changes

We update the "Last updated" date above when this policy changes. Material changes are announced [in our changelog / via Slack message / at (URL)].

9. Contact

[your-email@example.com]

Apps with complex data flows -- multiple AI providers, cross-workspace federation, or Slack Connect channels -- need additional sections for each data path. Want a policy generated from your app's actual data practices? Build one for free with the generator and get a hosted URL you can paste directly into your app's settings.

Hosting Your Policy and Setting the URL

The privacy policy URL must load over HTTPS, resolve without authentication, and display the full text without requiring a Slack login or app installation.

Your app's website -- a path like yourapp.com/privacy. Gives you full control over content, uptime, and branding.
A free generated policy -- generate and host a privacy policy at no cost and use the permanent URL it provides.
GitHub Pages -- a static HTML file in a public repository. Common for open-source Slack apps, works as long as it loads without a GitHub login.

Avoid Google Docs, Notion pages, or Pastebin links -- they can change visibility, move behind authentication, or disappear. Once you have the URL, go to api.slack.com/apps, select your app, open Manage Distribution, and paste the URL in the Privacy Policy URL field. For apps using an app manifest, set the settings.org_deploy_enabled or the display information's privacy_policy_url field. The URL is shown to workspace admins during the app's installation flow and on the App Directory listing page.

Frequently Asked Questions

Does every Slack app need a privacy policy?

Every app submitted to the public Slack App Directory must have a privacy policy URL. Internal apps distributed only within a single workspace are not required to have one by Slack, but it is still good practice, especially if the app handles message content or user data covered by GDPR.

What does Slack check during app review?

The review team verifies that the privacy policy URL is accessible, loads over HTTPS, and describes the app's data practices in enough detail to cover the OAuth scopes the app requests. Generic policies that do not mention Slack-specific data types -- OAuth tokens, workspace data, Events API payloads -- are flagged and the app is not approved until the policy is updated.

What data does a Slack app collect through OAuth?

At minimum, the OAuth flow returns a team.id, team.name, authed_user.id, and an access_token. Beyond that, each requested scope opens access to additional data: users:read exposes user profiles, channels:history exposes full message content in public channels, and files:read exposes shared file metadata and download links. Your policy must disclose what each requested scope accesses.

Do I need to handle the app_uninstalled event?

Yes. Slack's Developer Policy requires apps to delete workspace data when a workspace uninstalls the app. Subscribe to the app_uninstalled and tokens_revoked events in your app's Event Subscriptions, and build a handler that deletes all stored data for that workspace when either event fires.

How do I add a privacy policy URL to my Slack app?

Go to api.slack.com/apps, select your app, navigate to Manage Distribution, and enter the URL in the Privacy Policy URL field. The URL must load over HTTPS without requiring authentication. It appears to workspace admins during the installation flow and on your App Directory listing.

Does my Slack app's privacy policy need to cover the Events API?

If your app subscribes to any event types -- message.channels, message.groups, message.im, app_mention, file_shared, or others -- the policy must disclose that the app receives those event payloads. Each event delivers the sender's user ID, channel ID, and the event-specific data (message text, file metadata, reaction details). Even if the data is processed in memory and not stored, that processing must be disclosed.