How the Slack Marketplace actually works

A reviewed public catalogue of ~2,700 listings, sitting on top of a far larger population of ~1.7M apps used weekly. The catalogue is the small, governed tip of the platform; most Slack apps are customer-built and never listed.

Four actors, three trust boundaries. Slack owns the storefront and the review; the developer owns the code, the servers, the data and the liability; the customer owns the decision; the end user owns the consent.

Fig 1. Who builds, hosts, maintains and carries liability. Note the shape: Slack's boundary contains the storefront and the token authority but never the app's data; the developer's boundary contains the code and every liability; the customer's boundary contains both the consent and the content that leaves it.

Slack does not model internal, unlisted and listed apps as different product types. It is one app object moving through three distribution states, which is why the same dashboard serves a five-person hack and a listed ISV product.

Source: Slack distribution docs ^[1]

Slack builds more of the catalogue than people assume — but very little of it

Slack publishes first-party apps into its own Marketplace under Developer: Slack. Verified examples include Google Calendar, Google Meet, Slack for Gmail and Slack for Outlook^[30] — that is, the Google Workspace and Microsoft 365 integrations are built and maintained by Slack, not by Google or Microsoft. A systematic sample of 332 listings found 5 with Developer: Slack, ≈1.5%, implying roughly 40 first-party listings.^[35]

The capability classes Slack keeps for itself

Distribution surfaces and their gates

Activating public distribution requires OAuth 2.0 implemented and TLS on every endpoint — OAuth redirect URLs, interactivity request URLs, Block Kit options-load URLs and Events API request URLs; TLS 1.2+ has been mandatory since 19 Feb 2020.^[1] Activation yields an embeddable Add to Slack button, a shareable install URL, and the <meta name="slack-app-id"> tag. Deactivating it removes the app from every workspace except its home workspace — and once listed, you cannot deactivate this way at all; you must discontinue the listing.^[1]

Org-ready / org-wide (Enterprise Grid). Opt in via Org Level Apps; the manifest gains "org_deploy_enabled": true. The app is installed once at org level with a single org-wide token, then Org Admins grant it to specific workspaces. Two things developers get wrong: org-level install grants no additional privileges, and the app is not auto-added to any workspace. Detect with is_enterprise_install, key your storage on enterprise_id, and handle global user IDs beginning W.^[25][50]

App manifests make config portable and version-controllable — and there are two incompatible versions: Deno SDK apps use v2 exclusively, regular apps may use v1 or v2, and an absent version_metadata is treated as v1.^[46]

Legacy models: what is dead, dying, and unexpectedly resurrected

Two human review phases on top of automated tests, with an install-count floor that must hold for the entire review, and a queue that resets every time you resubmit in phase one.

Fig 2. The pipeline. The two resubmission loops are the operationally important detail: a preliminary-review bounce resets your queue position and restarts the clock on the functional review; a functional-review bounce after first feedback does not.^[2][4]

The install-count floor has whipsawed — get this one right

“Active” means used in the past 28 days, excluding sandboxes. Security & compliance partners using the Discovery API are exempt.^[3]

Categorically unsuitable — the ~25 disqualifiers

What the reviewer actually checks

Sources: Marketplace guidelines & requirements ^[3], review guide ^[4]

Newest category: MCP apps get their own checklist

MCP submissions require the mcp:connect bot scope, an HTTPS MCP server URL you own, OAuth via external_auth_providers with redirect URI https://oauth2.slack.com/external/auth/callback, and a successful Fetch Tools run. Every tool needs a human-readable title, an accurate description, a readOnlyHint annotation and a valid inputSchema. Slack states that “vague, misleading [descriptions]… will be grounds for rejection”; iframes must be scoped to the triggering tool call and must not replicate your whole product. Post-approval, iframe divergence “may result in app suspension” and sustained tool failures are “subject to auto-off enforcement.”^[33]

Listing is free with no revenue share, billing is entirely self-managed, and the listing carries a display-only price label. In exchange the developer accepts eight ongoing obligations and a config freeze.

There is no app certification — and claiming one is prohibited

The only badge Slack documents is the partner badge at Marketplace Partner tier and above. RED HERRING “Slack Certified” redirects to a human professional-credential program, not an app certification — do not conflate the two.^[29]

The live app is locked after publish

Dashboard changes do not affect the published app until re-review passes, so Slack requires you to maintain a separate staging app cloned from your published manifest and distributed so reviewers can test it. The concrete failure mode Slack calls out: adding un-reviewed scopes to your install link makes installs error out for customers. A video demo and test app are required for new functionality, new scopes, or anything touching the privacy model — but not for display info, pricing, language support or URL updates. “If in doubt, provide a video demo.”^[2]

Eight post-approval obligations

Source: Slack Marketplace distribution guide ^[2]

The enforcement ladder

Slack contacts you when expectations are not met, users report spammy behaviour, broken functionality or poor support, when uninstalls increase, when error rates rise, or when your support/privacy links break. If you do not respond, Slack “will reach out again while simultaneously delisting your app to protect users.” Delisting happens without prior notice when the landing page or install flow is broken, the app appears abandoned, or functionality changed substantially without resubmission.^[2]

Sunsetting, and the auto-uninstall trap

Slack's four-step discontinuation checklist: remove from the Marketplace, contact the Marketplace team, contact your customers, and delete and revoke every token your app generated. The Developer Policy adds a hard deadline — on user deletion or discontinuation, delete all associated data within 14 business days.^[5] Note you cannot use “Deactivate Public Distribution” once listed.^[1]

Everything an app can ever do is decided in one screen, by one person, in about four seconds. No token, no API — and the token's power is fixed at the moment of consent.

Fig 3. Install and consent. Steps 1–4 are the trust transfer; step 5 is the only place an organisation can intervene, and it is disabled until someone turns it on.^[11][18][19]

Why Slack designed it this way — in Slack's words

Reinstall triggers — where re-consent is forced

Slack sees that an app read your data. It does not see what the app does next. Everything past the developer's ingress is governed by contract and audited by nobody.

Fig 4. The privacy boundary. Left of the token, Slack's compliance estate applies. Right of it, nothing does except the developer's own promises.^[55][58][69]

Scope risk tiers

Sources: scope reference ^[58], tokens ^[60], search:read ^[59], Discovery ^[61], Real-Time Search ^[62]

There are two parallel contractual stacks and no contract between the customer and the app developer. Both stacks bar third-party beneficiaries. That gap is the entire liability story.

Fig 5. The contractual stack. Note the asymmetry: the broad indemnity runs developer→Slack, and the one arrow a harmed customer would want — developer→customer — does not exist.^{[51][6][5][8][56]}

Four documents, one message: Slack is a distributor, not a warrantor

The indemnity and liability map

What actually happens when a third-party app is breached

Documentation hygiene problems worth knowing about

Slack ships a genuinely deep control plane. The single most consequential fact about it is that app approval is not enabled until an admin turns it on.

Workspace level

The audit trail an admin actually gets

Source: audit-logs actions reference ^[67]. Enterprise Grid only, auditlogs:read, org-Owner install, read-only, no message content.

Developer-side controls

Slack gives an app roughly eleven ways to reach a human. They are not interchangeable, and Slack has published a design intent for nearly every one — the recurring theme is keep the human the initiator.

Fig 6. Surfaces by initiative and intrusiveness. Almost all of Slack's design guidance pushes apps down and to the left.^[24][44]

Slack's stated intent, surface by surface

Surface selection matrix

Source: choosing the right surface ^[24], surfaces overview ^[44]

Transport choice is constrained by listing ambition

Incoming webhooks are the minimal path — 1 message/second, and they cannot delete or update messages. Slack adds a warning worth repeating: “Slack actively searches out and revokes leaked secrets.”^[43]

An app cannot reach a human before that human acts. There is exactly one pre-install contact path in the entire platform, and Slack — not the app — operates it.

The one exception — and Slack keeps control of it

App Suggestions is the only mechanism by which a Slack user hears about an app before installing it in-product, and the app never touches it. The developer adds <meta name="slack-app-id"> to their site; Slack crawls it; when someone pastes that link into a channel, Slack sends an ephemeral message — visible only to the person who posted the link — offering Yes please Not now No thanks, where No thanks is a permanent opt-out. It is available only to Marketplace-listed apps.^[13]

Rate-limit tiers — the etiquette policy, expressed as quota

Fig 7. Tiers are per-method and per-workspace. Source: rate limits ^[9], 2025 changelog ^[10]. Burst allowances are deliberately undisclosed.

What the Developer Policy forbids outright

Offboarding — the two events, and the trap in them

Uninstallation fires app_uninstalled and tokens_revoked. Both are Events-API-only and require no scopes. Two implementation details that break naive token stores:

See also the auto-uninstall rules in §05: apps holding any scope beyond bot/incoming-webhook/commands/identify are auto-uninstalled when the installing user leaves the workspace or becomes a guest — an offboarding path with no developer involvement at all.^[1]

An agent is an app that acts. Slack's response is a dedicated container, three published principles, and a governance layer — plus the most candid warning in any of its documentation.

The container and its mechanics

The demonstrated attack: prompt injection through a public channel

In August 2024, PromptArmor demonstrated a chain in which an attacker plants injected instructions in a public channel — requiring no membership in the victim's private channel — and Slack AI renders an exfiltrating link that leaks private-channel content, including API keys. Slack initially characterised the underlying behaviour as “intended behavior”, on the grounds that public-channel content is legitimately searchable, before Salesforce patched it. The technique was later extended to injection via uploaded files.^[77]

The compounding problem: cross-app chains

A 2026 analysis defines a “toxic combination” as “a permission breakdown between two or more applications, bridged by an AI agent, integration, or OAuth grant, that no single application owner ever authorized as its own risk surface,” and gives a Slack-shaped example: an MCP connector wiring an IDE to a Slack channel, where “prompt injections inside the IDE push confidential code into Slack, and instructions planted in Slack flow back into the IDE's context on the next session.” It cites the CSA State of SaaS Security 2025 finding that 56% of organisations are concerned about over-privileged API access across SaaS-to-SaaS integrations.^[79] Slackbot itself now acts as an MCP client across enterprise apps, which widens exactly this surface.^[33]

Slack's distinctive choices are the 0% take rate with no billing rail, the explicit anti-certification stance, and a review that is unusually long for a marketplace that extracts no revenue.

For a blueprint, the instructive events are not the launches. They are the reversals — and Slack has had several, including two in the last year.

Fig 8. Additive changes above the spine, breaking changes below, reversals boxed. Dated changelog sources throughout.^{[26][31][32][47][49]}

Slack platform & distribution documentation

1. [1] Distributing Slack apps — docs.slack.dev/app-management/distributing-your-app
2. [2] Distributing your app in the Slack Marketplace — docs.slack.dev
3. [3] Slack Marketplace app guidelines & requirements — docs.slack.dev
4. [4] Slack Marketplace review guide — docs.slack.dev
5. [5] Slack Application Developer Policy — docs.slack.dev/developer-policy · effective 10 Dec 2024
6. [6] Slack API Terms of Service — slack.com/terms-of-service/api · effective 10 Oct 2025
7. [7] Slack Application Security Review — docs.slack.dev
8. [8] Slack Marketplace Agreement — slack.com/terms-of-service/slack-marketplace · last modified 11 Jul 2016
9. [9] Rate limits — docs.slack.dev/apis/web-api/rate-limits
10. [10] Changelog: rate-limit changes for non-Marketplace apps — docs.slack.dev · 29 May 2025
11. [11] Installing with OAuth — docs.slack.dev/authentication/installing-with-oauth
12. [12] App design guidelines — docs.slack.dev/concepts/app-design
13. [13] Onboarding users to your app — docs.slack.dev/onboarding-users-to-your-app
14. [14] App Home — docs.slack.dev/surfaces/app-home
15. [15] Split view — docs.slack.dev/surfaces/split-view
16. [16] AI agents — docs.slack.dev/ai
17. [17] Agent governance — docs.slack.dev/ai/agent-governance
18. [18] Managing app approvals (admin API) — docs.slack.dev/admins/managing-app-approvals
19. [19] Manage app approval for your workspace — slack.com/help/articles/222386767
20. [20] Add and update apps — slack.com/help/articles/202035138
21. [21] Remove apps and custom integrations — slack.com/help/articles/360003125231
22. [22] app_uninstalled event — docs.slack.dev
23. [23] tokens_revoked event — docs.slack.dev
24. [24] Choosing the right surface — docs.slack.dev
25. [25] Organization-ready apps — docs.slack.dev
26. [26] Changelog: classic-apps deprecation paused — docs.slack.dev · 8 Dec 2025
27. [27] Workflow steps — docs.slack.dev/workflows/workflow-steps
28. [28] Deno Slack SDK — docs.slack.dev/tools/deno-slack-sdk
29. [29] Slack partner program — slack.com/partners
30. [30] Slack Marketplace — slack.com/marketplace and docs.slack.dev/slack-marketplace
31. [31] Changelog: Marketplace install requirement — docs.slack.dev · Jul–Sep 2026
32. [32] Changelog: Slack Marketplace install threshold reduced — docs.slack.dev · 11 Aug 2025
33. [33] Slackbot MCP client — distributing & admin approval — docs.slack.dev
34. [34] Partner sandboxes — docs.slack.dev/tools/partner-sandboxes
35. [35] Marketplace sitemap · used for the first-party listing sample — slack.com/sitemaps/sitemap_marketplace_en-us.xml
36. [36] Sending and scheduling messages — docs.slack.dev
37. [37] chat.postEphemeral — docs.slack.dev
38. [38] chat.postMessage — docs.slack.dev
39. [39] Unfurling links in messages — docs.slack.dev
40. [40] Implementing slash commands — docs.slack.dev
41. [41] Implementing shortcuts — docs.slack.dev
42. [42] Comparing HTTP & Socket Mode — docs.slack.dev
43. [43] Incoming webhooks — docs.slack.dev
44. [44] Surfaces overview — docs.slack.dev/surfaces
45. [45] Slack brand guidelines — slack.com/media-kit
46. [46] App manifests — docs.slack.dev/app-manifests
47. [47] Changelog: legacy custom bots & classic apps deprecation — docs.slack.dev · Sep 2024, superseded by [26]
48. [48] Legacy RTM API — docs.slack.dev/legacy/legacy-rtm-api
49. [49] Changelog: Steps from Apps step back — docs.slack.dev · Aug 2023; retirement 26 Sep 2024
50. [50] Developing for Enterprise Grid — docs.slack.dev

Legal, privacy, security & governance

1. [51] Salesforce Main Services Agreement — slack.com/main-services-agreement · index last updated 25 Apr 2023
2. [52] Slack Supplemental Terms — slack.com/slack-supplemental-terms
3. [53] Slack User Terms of Service — slack.com/terms-of-service/user
4. [54] Slack Acceptable Use Policy — slack.com/acceptable-use-policy · 8 Jul 2025
5. [55] Slack Privacy Policy — slack.com/trust/privacy/privacy-policy · effective 5 Jul 2023
6. [56] Salesforce Data Processing Addendum · header “Revision August 2026”, footer “April 2026” — salesforce.com (PDF)
7. [57] Security recommendations for approving apps — slack.com/help/articles/360001670528
8. [58] Scope reference — docs.slack.dev/reference/scopes
9. [59] search:read scope · flagged legacy — docs.slack.dev
10. [60] Token types — docs.slack.dev/authentication/tokens
11. [61] A guide to Slack's Discovery APIs — slack.com/help/articles/360002079527
12. [62] Real-Time Search API · formerly Data Access API — docs.slack.dev
13. [63] Data residency for Slack — slack.com/help/articles/360035633934
14. [64] Managing apps, workflows & connector permissions — docs.slack.dev
15. [65] MCP client admin approval — docs.slack.dev
16. [66] Enterprise Key Management — slack.com/enterprise-key-management
17. [67] Audit logs — methods & actions reference — docs.slack.dev
18. [68] Audit logs — anomalous events reference · search_volume deprecated 2 May 2025 — docs.slack.dev
19. [69] Security best practices — docs.slack.dev/concepts/security
20. [70] Using token rotation — docs.slack.dev
21. [71] Slack compliance & certifications — slack.com/trust/compliance
22. [86] Audit Logs API overview — docs.slack.dev/admins/audit-logs-api
23. [84] mcp:connect scope — docs.slack.dev
24. [83] Slack on HackerOne · JS-gated; third-party app scope UNVERIFIED — hackerone.com/slack

Incidents & third-party reporting

1. [72] Slack bot tokens leaked on GitHub — The Register · 28 Apr 2016 — theregister.com
2. [73] Slack API abused as covert C2 (“Aclip”, ITG17) — BleepingComputer · 15 Dec 2021 — bleepingcomputer.com
3. [74] Slack password hashes exposed in invitation links · flaw live 17 Apr 2017 – 17 Jul 2022 — bleepingcomputer.com
4. [75] Slack ML-training terms controversy — The Register · 20 May 2024 — theregister.com
5. [76] NullBulge / Disney Slack breach — 1.1 TB, ~10,000 channels · guilty plea 1 May 2025 — bleepingcomputer.com
6. [77] Slack AI prompt-injection exfiltration (PromptArmor) — The Register · 21 Aug 2024 — theregister.com
7. [78] Salesloft Drift OAuth token theft (UNC6395), 700+ tenants — The Hacker News · 27 Aug 2025 — thehackernews.com
8. [79] “Toxic combinations” cross-app risk · 22 Apr 2026 · VENDOR-SPONSORED CONTENT — thehackernews.com
9. [80] OAuth consent phishing bypassing MFA (EvilTokens) · 19 May 2026 · VENDOR-SPONSORED CONTENT — thehackernews.com
10. [81] Salesforce disables Klue integration (Drift → Gainsight → Klue pattern) · Jun 2026 — thehackernews.com
11. [82] Fivetran Open Data Index — Slack scored poorly on programmatic access — The Register · 22 Apr 2026 — theregister.com
12. [85] Slackbot as MCP client across enterprise apps — The Register · 2 Apr 2026 — theregister.com

Sources [72]–[85] were located and verified as reachable; a small number of additional headlines were found via the Wayback CDX index but not read, and are therefore deliberately excluded from this list rather than cited unread.