A great Slack app doesn’t just work well. It also earns trust by being careful with permissions, secure with data, and reliable under load. For Marketplace apps, that trust extends across every workspace where your app is installed.

The previous post in this series covered building an experience people want to use. Now let’s look at what makes people feel secure using it: permissions, security, and reliability.

Request only the permissions you need

Trust starts with permissions. When distributed, a workspace admin or installer has to approve every scope your app requests. Every scope on that list is a promise about how you’ll use their data.

To get this right, use Slack’s Granular Permissions model to request only what’s essential for your core functionality. When your app’s capabilities expand, request new scopes incrementally rather than asking for broad access up front. 

Many workspaces require admin approval before any app can be installed. When an admin reviews your app, they see every scope it requests and decide whether that level of access is appropriate for their organization. The fewer scopes you request, the easier that makes their decision. 

Secure your tokens and endpoints

Your tokens grant access to your users’ workspaces. If they’re compromised, so is everything they unlock. Protecting them protects your users.

A basic way to do this is to make sure every endpoint uses HTTPS. For this reason, Slack requires HTTPS for redirect URIs. Additionally, keep tokens out of client-side code, URLs, and logs, sending them only in the Authorization HTTP header.

Beyond transport security, use the safeguards built into the OAuth flow. The state parameter, for example, prevents CSRF attacks by verifying the callback matches a request your app initiated. Generate a unique value before redirecting to Slack, then confirm it on the callback before exchanging the code for a token. The OWASP Top 10 is a good baseline for your web application’s security posture, and SSL Labs can help you verify your TLS configuration.

Handle their data responsibly

People trust your app with their workspace data. Every decision about collection, retention, and deletion reflects that trust. Get these wrong and that trust disappears.

Collect data only with user consent. Delete user data promptly when your app is uninstalled, and retain data only as long as necessary for your app’s function. Notify users and Slack immediately upon any data breach.

Any contact information your app collects through the Slack API, including email addresses, is personally identifiable information. Store it securely, and don’t use it to contact users without their explicit permission.

Slack’s developer policy sets clear boundaries around data use. Keep collected data within your app’s stated purpose. Only collect what your scopes require. Never use it to train a large language model (LLM), sell it to third parties, or monitor users in ways they haven’t consented to.

To give users informed consent, your app must have a publicly accessible privacy policy. It should cover what data you collect, how it’s used, and how long it’s retained. Provide a way for users to request access or deletion of their data. Even a lightweight app needs to tell users what it collects and why.

If your app uses an LLM, additional requirements apply. Add a disclaimer to your landing page and listing description noting the potential for inaccurate outputs. In the security and compliance section of your listing, disclose the model your app uses. Include how the LLM handles data retention and where data resides.

Respect rate limits by design

A reliable app works within the platform’s capacity. If your app hits rate limits regularly, that’s a signal to rethink how it batches or queues requests.

Slack enforces rate limits per method, per workspace, on a per-minute basis. They’re organized into tiers based on how frequently a method is expected to be called. Messages are limited to 1 per second per channel, and incoming webhooks to 1 per second. The Events API has a separate delivery cap covered in the section below.

If you do hit a limit, Slack returns a 429 with a Retry-After header telling you exactly how long to pause. Honor that timing before retrying, and use exponential backoff for repeated failures.

The best approach is to design your architecture around these limits from the start. A message queue that drains at a steady rate keeps you within posting limits. Caching responses from read-heavy endpoints reduces unnecessary API calls. Batching operations where the API supports it lets you do more with fewer requests.

Respond to events reliably

The Events API delivers events to your app in real time. Dropping them means broken behavior for your users.

Acknowledge each event quickly with an HTTP 2xx, then push it to a queue and process it asynchronously. If your app fails to acknowledge, Slack retries with increasing delays. Drop too many and Slack will temporarily disable your event subscriptions. See the Events API documentation for specific timing and threshold requirements.

Slack also offers tools to help you recover gracefully, from extended retry windows during outages to signals that tell your app when to slow down. The Events API documentation also covers what’s available.

Permissions, security, data handling, and reliability are what make users and admins confident enough to keep your app installed. The next post in this series gives an overview to publishing and maintaining your listing. For a deeper look at how to scope permissions for the Marketplace, see Less Is More: A Slack Approach to Scopes.