# How to Publish a Slack App: A Marketplace Release Guide for Indie Makers

> Learn how to publish a Slack app through private testing, public distribution and Slack Marketplace review, with practical checks for OAuth, trust and activation.

- Canonical: https://zeroraised.com/blog/how-to-publish-a-slack-app
- Published: 2026-10-18
- Updated: 2026-10-18
- Author: Jay Mokashi (https://zeroraised.com/blog/authors/jaymokashi)
- Publisher: ZeroRaised (https://zeroraised.com/)
- Section: Growth
- Tags: slack-apps, marketplaces, oauth, product-launch

To learn how to publish a Slack app, first choose single-workspace use, unlisted public distribution or a Slack Marketplace listing. Multi-workspace installation needs OAuth, while Marketplace publication adds review, listing, privacy, support and onboarding requirements. Test the complete install and first-use path before submitting ([Slack distribution guide](https://docs.slack.dev/app-management/distribution), checked 18 Oct 2026).

**Disclosure:** ZeroRaised publishes this guide and makes no promise of traffic or results.

## TL;DR

- Keep the app attached to one workspace while the product and permission model are still changing. Slack says a new app is associated with one workspace by default ([Slack distribution guide](https://docs.slack.dev/app-management/distribution), checked 18 Oct 2026).
- Add OAuth before inviting other workspaces. The flow requests scopes, receives approval and exchanges a temporary code for an access token ([Slack OAuth guide](https://docs.slack.dev/authentication/installing-with-oauth), checked 18 Oct 2026).
- Use unlisted public distribution for controlled pilots, then pursue the Marketplace when the app, support process and public pages are ready. Slack recommends Marketplace approval for apps intended for commercial distribution ([Slack distribution guide](https://docs.slack.dev/app-management/distribution), checked 18 Oct 2026).
- Treat installation as the start of onboarding. Slack reviews the experience of both the installer and other first-time users ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

On 14 Oct 2026, the Show HN post **“Merlin, Run Your Claude Code and Codex from Slack, Linear and GitHub”** explained that tasks run on a team member's machine, provider credentials stay on the device, required context passes through Merlin, and an offline or sleeping machine cannot accept work. It also identified Linux as CLI-only at the time. That is a useful model for an integration release: say where work happens, what data moves, who can use the system and which limits remain ([Show HN thread](https://news.ycombinator.com/item?id=50088088) and [Merlin product site](https://usemerlin.ai), checked 18 Oct 2026).

Do not copy Merlin's positioning or treat one launch as a result forecast. Copy the discipline of answering trust questions before a prospective installer has to ask them.

## How to publish a Slack app without choosing the wrong route

“Publish” can mean three different things in Slack. It can mean installing an app in the workspace where it was created, activating a public OAuth link so other workspaces can install it, or earning [a reviewed Marketplace listing](https://zeroraised.com/launch-sites/slack-marketplace). Those routes are related, but they are not interchangeable ([Slack distribution guide](https://docs.slack.dev/app-management/distribution), checked 18 Oct 2026).

| Route | Who can install | What you need | Discovery | Sensible use |
|---|---|---|---|---|
| Single-workspace app | Members of the associated workspace, subject to that workspace's controls | The app can be installed to its associated workspace without building an authorisation handler | No public Marketplace listing | Development, internal use and early testing |
| Unlisted public distribution | Other workspaces through the public installation URL | An OAuth flow, secure request URLs, install storage and a repeatable onboarding path | You distribute the URL yourself | A controlled pilot with named customers |
| Slack Marketplace listing | Eligible Slack customers, subject to workspace approval settings | Public distribution plus Slack's prerequisites, submission information, functional review and compliant listing pages | Search and browsing within the Marketplace | A production-ready app intended for continuing public distribution |

The route details in this table come from Slack's current distinction between undistributed, unlisted distributed and listed distributed apps ([Slack distribution guide](https://docs.slack.dev/app-management/distribution), checked 18 Oct 2026). “Sensible use” is editorial guidance, not a Slack rule.

Choose by product maturity, not prestige. If you still change scopes after every user conversation, keep testing. If a small group can install and receive value but you need evidence from more workspaces, use a controlled unlisted pilot. If strangers can install, understand, use, remove and get support without your private intervention, prepare for review.

This order matters because public distribution creates operational work. Each installation can create workspace-specific credentials, configuration and support questions. Slack explicitly warns that hands-on help which works for one workspace will not scale across many, so distributed apps need a proper onboarding flow ([Slack distribution guide](https://docs.slack.dev/app-management/distribution), checked 18 Oct 2026).

### Decide what one successful installation means

Before touching the distribution switch, write a one-sentence activation definition. This is an editorial exercise, not a Slack requirement. It should identify the user, the action and the useful result.

**Illustrative example:** “A workspace is activated when an authorised member connects the external account, selects a permitted channel and completes the first successful hand-off from Slack.”

## Build the OAuth install flow before public distribution

Slack uses its v2 OAuth flow for app installation. At a high level, your app sends a user to Slack with the required scopes, waits for approval, receives a temporary authorisation code at an HTTPS redirect URI, and exchanges that code through `oauth.v2.access`. The response identifies the resulting workspace or Enterprise installation and includes the issued token data ([Slack OAuth guide](https://docs.slack.dev/authentication/installing-with-oauth), checked 18 Oct 2026).

Build the path as a product flow, not a back-office plumbing task:

1. **Start from a clear install page.** Say what the app will do in Slack and what account, plan or external service is needed. Slack requires a public app-specific landing page for Marketplace submissions, with an install path and clear next steps ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).
2. **Send the user to Slack for consent.** Put bot scopes in `scope` and user-token scopes in `user_scope`. Slack advises using a bot token unless the app really needs to act for a particular user ([Slack OAuth guide](https://docs.slack.dev/authentication/installing-with-oauth), checked 18 Oct 2026).
3. **Protect the return.** Use an HTTPS redirect URI that matches the configured value, validate `state`, and exchange the short-lived code on the server. Slack documents the redirect matching rules and says the temporary code expires after ten minutes ([Slack OAuth guide](https://docs.slack.dev/authentication/installing-with-oauth), checked 18 Oct 2026).
4. **Store the installation against the correct tenant.** Read the workspace or Enterprise identifiers from the access response rather than assuming the target named at the start remained selected. Slack calls that response the source of truth for the completed target ([Slack OAuth guide](https://docs.slack.dev/authentication/installing-with-oauth), checked 18 Oct 2026).
5. **End with an explicit result.** Show success and the next action, or show a specific error and recovery route. Slack recommends telling the user how the flow ended, and its Marketplace guidance requires clear post-install steps ([Slack OAuth guide](https://docs.slack.dev/authentication/installing-with-oauth) and [Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

Test cancellation, a denied permission, an invalid state, an expired code, a repeated install and the wrong external account. Those cases are editorial test recommendations. Also test uninstalling and reinstalling from a workspace that is not your development workspace, because Slack tells Marketplace applicants to run the full path as a new customer would, including removal ([Marketplace review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide), checked 18 Oct 2026).

### Request the smallest defensible set of scopes

Create a scope worksheet with four columns: product action, Slack API method or event, required scope, and why a less permissive option does not work. The worksheet is an editorial template, but the principle is Slack's: request the smallest number of least-permissive scopes that still provide the intended experience ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

Do not add broad permissions because a future feature might use them. Reviewers inspect how each requested scope supports current functionality, and Slack's guidance rejects unnecessary access where a less permissive choice exists ([Marketplace review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide) and [Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

Scope changes also affect existing customers. Slack says adding scopes changes what new installations request, while existing tokens retain their old grants until a workspace reauthorises. Removing a scope from configuration does not remove it from an already-issued token until revocation or uninstall ([Slack distribution guide](https://docs.slack.dev/app-management/distribution), checked 18 Oct 2026). Plan the customer message and reinstallation path before shipping a permission change.

### Design for admin approval, not just member intent

A member clicking “Add to Slack” may not be allowed to finish. Workspaces can require an administrator to review app requests, and some can restrict installation to apps listed in the Slack Marketplace. The request exposes the permissions involved, so a concise scope explanation helps an administrator understand the trade-off ([Slack distribution guide](https://docs.slack.dev/app-management/distribution), checked 18 Oct 2026).

Prepare a short admin packet. This is an editorial recommendation. Include the app's purpose, requested scopes with plain-English reasons, data categories, storage and deletion approach, support contact, privacy policy, security contact and removal steps. Make it available from the installation page so the original requester can forward one stable link.

When approval is pending, say so. Do not show a generic failure screen or ask the member to repeat OAuth indefinitely. Slack documents that, where approval settings are enabled, a user requests the app and an admin approves it before installation ([Slack admin approval guide](https://docs.slack.dev/admins/managing-app-approvals), checked 18 Oct 2026). Your own product state should distinguish “request created”, “approved but setup incomplete” and “installed and activated”.

## Prepare the public pages and Marketplace assets

The listing is only one part of the trust surface. Slack's submission requirements call for a public, app-specific landing page, a public support page and a privacy policy linked from the landing page. The landing page should explain the problem, show how the service works in Slack, provide an install path and direct a successful installer to the next step ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

### Write a privacy policy that describes the actual data path

Start with a data inventory, not generic legal wording. List what arrives from Slack, what comes from an external account, what is stored, where it is processed, who can see it, how long it is retained and how deletion works. Get appropriate legal advice for your circumstances. This guide is a product checklist, not legal advice.

Slack says the policy must describe collected data, its use, retention, access or transfer or deletion requests, and a contact route. It also says that data received but not used still needs to be disclosed, including identifiers arriving in command payloads or system logging ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

Use Merlin's launch explanation as a communication prompt, not as policy text. Its Show HN post separated local working files and provider credentials from the request and context that pass through Merlin ([Show HN thread](https://news.ycombinator.com/item?id=50088088), checked 18 Oct 2026). For your app, draw the equivalent boundary accurately. If message text is processed, say so. If an external model or service receives it, name that category and explain the purpose. If you cannot substantiate “we never store X”, do not write it.

### Make support possible without another account

Slack expects the public support page to offer an email address or contact form, remain accessible without a login and provide a route that does not require an account on another service. Its current guideline expects support requests to receive a response within two business days ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

For a small team, publish the support hours and collect the facts needed to diagnose an issue: workspace identifier, approximate time, feature used, visible error and permission to inspect relevant logs. Do not ask customers to paste tokens, client secrets or private message contents. Slack's security guidance says tokens, keys and credentials must not be exposed in public code, client-side code or error messages ([Slack security guidance](https://docs.slack.dev/concepts/security), checked 18 Oct 2026).

### Build listing copy and images around the in-Slack result

The short description should say who the app helps and what changes inside Slack. The long description can explain the workflow, permissions and external account relationship. Avoid claiming capabilities shown only in a future roadmap.

Slack currently asks Marketplace images to be high quality, 1600 by 1000 pixels, in JPG, JPEG or PNG format, under 2 MB, and to show the product in Slack rather than an unrelated interface. It requires app images in the listing and may return a submission with low-quality or irrelevant visuals ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

Use each screenshot to answer one question: what starts the workflow, what the app returns, what a user can control, and where help lives. Use believable demonstration data with no customer secrets. Captions should explain the result rather than repeat the button label. These are editorial recommendations.

## Onboard the installer and the rest of the workspace

There are at least two people to design for: the member who authorises or requests the app, and the colleague who encounters it later. Slack's requirements explicitly tell developers to guide both the installer and first-time users, provide clear next steps, show progress, surface support and move people towards value during onboarding ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

Give the installer a compact setup sequence:

1. Confirm the correct workspace and external account.
2. Explain which Slack surfaces the app will use.
3. Ask for any required channel or project selection.
4. Run a safe first action with preview or confirmation where appropriate.
5. Show the result and one next useful action.
6. Put settings, privacy and support within reach.

This sequence is an illustrative template. Remove steps the product does not need. The goal is to reach the activation definition without turning setup into a tour of every feature.

Then handle an unrecognised colleague gracefully. If that person uses a shortcut, command or App Home without a linked external account, explain what the app is, whether they are allowed to connect, and what happens next. Slack's guidance notes that shortcuts and commands can be accessible to anyone in an installed workspace and says apps should handle unrecognised users clearly ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

An App Home can hold status, settings, onboarding instructions and support details. Slack specifically suggests App Home for customised onboarding and asks listed apps to make support and applicable pricing visible there ([Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026). Do not enable an empty Home tab merely to tick a box.

## Submit for Slack Marketplace review

Submit only after the unlisted app behaves like the product customers will receive. Slack says an app should be fully functional, publicly available, installable, tested outside the development workspace and ready for ongoing maintenance and support. Its current prerequisites require installation on 10 or more active workspaces, with the service tested there. Separately, Slack says apps installed on fewer than 10 active workspaces and with fewer than 10 weekly active users are not suitable for listing. Coded workflows are currently ineligible for listing ([Marketplace review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide) and [Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026).

Do not manufacture those prerequisites. Recruit relevant pilot workspaces, obtain permission to support them and learn from real use. If the app cannot retain the required genuine activity, another round of product work is more useful than a rushed submission.

Slack asks submitters to review listing information and scopes, and to provide what reviewers need to test. That can include service credentials, a working way for Slack to install the app in its own test workspace, and a short video covering OAuth, setup, use and removal. Slack says not to provide credentials for a Slack workspace itself ([Marketplace review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide), checked 18 Oct 2026).

| Check | Evidence to prepare | Why it matters | Source |
|---|---|---|---|
| Distribution | A working public OAuth URL tested outside the development workspace | Reviewers install the app as a new customer would | [Review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide), checked 18 Oct 2026 |
| Permissions | Scope worksheet tied to current features and API use | Slack reviews whether access is necessary and appropriately narrow | [Review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide), checked 18 Oct 2026 |
| End-to-end test | A clean run through install, setup, first action, errors and uninstall | The submitted product should arrive production-ready | [Review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide), checked 18 Oct 2026 |
| Public pages | Landing, support and privacy URLs accessible without a login where required | Customers and reviewers need clear product, help and data information | [Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026 |
| Listing assets | Accurate copy, icon and in-Slack screenshots in the required formats | The listing must show what the installed experience does | [Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026 |
| Reviewer access | Service test account, install instructions and concise video | Reviewers need to exercise gated or connected features | [Review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide), checked 18 Oct 2026 |
| Support readiness | Public contact route, ownership and response routine | Listed apps require continuing support | [Marketplace requirements](https://docs.slack.dev/slack-marketplace/slack-marketplace-app-guidelines-and-requirements), checked 18 Oct 2026 |

At the time checked, Slack says the preliminary review can take up to ten business days and the functional review up to ten weeks for new submissions, with timing varying by volume. Slack cannot accelerate review to match a release date, but an approved maker can choose when to publish ([Marketplace review process](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide), checked 18 Oct 2026). Treat those figures as current guidance, not a guaranteed schedule. Check the estimate shown in the app's own submission page before planning an announcement.

When feedback arrives, answer each point with the change, where it can be tested and any updated video timestamp. That response format is editorial advice. Do not argue from intent when the reviewer observed a broken outcome. Repair the path, retest it from a clean workspace and reply with reproducible evidence.

## Measure installs, activation and retention

An OAuth callback tells you that an installation reached the token exchange. It does not tell you that setup finished or anyone received value ([Slack OAuth guide](https://docs.slack.dev/authentication/installing-with-oauth), checked 18 Oct 2026). Track a short funnel in your own product, using the minimum data needed and reflecting that collection in the privacy policy.

| Stage | Example event | Diagnostic question | Do not confuse it with |
|---|---|---|---|
| Install started | User leaves the app page for Slack authorisation | Did the promise create enough intent to inspect permissions? | A completed install |
| Install completed | Valid OAuth response stored for the workspace | Did authorisation and token exchange work? | Completed setup |
| Setup completed | Required account and channel choices saved | Can the workspace use the intended workflow? | A useful result |
| Activated | The defined first useful action succeeds in Slack | Did a user receive the core value? | Any command invocation |
| Repeated use | Another useful action succeeds in a later session | Is the workflow worth returning to? | Automated noise |
| Removed | Credentials revoked and tenant marked uninstalled | Where did the product or trust path fail? | A dormant workspace |

These event definitions are editorial examples, not Slack's universal metric names. Slack provides an `app_uninstalled` event, and its security guidance says customer authentication secrets should be deleted when the integration is removed ([Slack `app_uninstalled` event](https://docs.slack.dev/reference/events/app_uninstalled) and [Slack security guidance](https://docs.slack.dev/concepts/security), checked 18 Oct 2026).

Break the funnel down by workspace, install source and product version without exposing private workspace content. Review failures as paths: permission denied, approval pending, callback error, account connection abandoned, first action failed, or no second use. A raw install total hides all of those different problems.

Talk to pilot users as well. Ask the installer why they trusted the app, what an administrator questioned, where setup became unclear and whether colleagues understood the first interaction. Ask for a real recent example rather than a general opinion. This is product-research advice, not a claim that one interview pattern predicts every customer.

## Announce the app after approval

Prepare the announcement while review is in progress, but do not promise a fixed publication date until approval is complete. Your core release note should answer:

- Who is the app for?
- What job can they complete from Slack?
- What moves between Slack and the connected service?
- Which permissions are requested, and why?
- What must an administrator approve?
- What can a new user try first?
- What limitation should they know before installing?
- Where can they get help or request deletion?

Merlin's 14 Oct Show HN post is a current named example of this pattern because it explained execution location, device-held credentials and files, shared runtime choices, supported systems and known operating limits ([Show HN thread](https://news.ycombinator.com/item?id=50088088), checked 18 Oct 2026). Its specifics are Merlin's, not a checklist of claims another app may reuse.

Publish first on your own product site and Marketplace page, then choose communities where the app and the explanation are relevant. If the product can be tried and the technical story is genuinely interesting, the [Show HN writing guide](https://zeroraised.com/blog/how-to-write-a-show-hn-post) covers that community's format. For the broader release sequence, use the [product launch checklist](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers) (both checked 18 Oct 2026).

[ZeroRaised](https://zeroraised.com/) is for products with no institutional VC or accelerator equity under its published eligibility policy. An eligible maker can use the [submission form](https://zeroraised.com/submit) for a public product page, and should read the form before preparing the release ([ZeroRaised submission page](https://zeroraised.com/submit), checked 18 Oct 2026). This is an additional discovery route, not a substitute for Slack review, product support or direct customer learning.

Keep the listing and announcement consistent. If the pricing model, scope set or supported workflow changes during review, update the affected copy before release. The [ZeroRaised perks page](https://zeroraised.com/perks) lists confirmed maker offers separately from editorial release guidance; it does not promise an audience or product outcome (checked 18 Oct 2026).

### A practical release sequence

Use this as an editorial sequence, adjusting it to support capacity:

1. Confirm Marketplace publication and re-run the production install from a clean workspace.
2. Check the landing, privacy and support links in a signed-out browser.
3. Exercise the first useful action as both the installer and a colleague.
4. Verify error reporting, removal handling and the support inbox.
5. Publish the product-site note and update the install button.
6. Submit an eligible product through [ZeroRaised](https://zeroraised.com/submit) and make only community posts that match each venue's rules.
7. Watch setup failures and support requests, then fix the earliest repeated blocker.

The final step is the important one. Publication changes who can encounter the app; it does not prove that the product is clear, trusted or useful. Use the first release to compare installs with setup and activation, preserve the privacy promises you made, and improve the first in-Slack result.

## What to do next

Choose the route now. If the app only works with your help, keep it in a small test group and repair onboarding. If several real workspaces can install and activate it through OAuth, use an unlisted pilot to harden support and permissions. If the product meets Slack's current [review prerequisites](https://docs.slack.dev/slack-marketplace/slack-marketplace-review-guide) and a stranger can complete the path, prepare the reviewer evidence and submit (checked 18 Oct 2026).

The durable version of how to publish a Slack app is not “turn on distribution and announce it”. It is: pick the right route, minimise access, make the data path understandable, pass review honestly, guide two kinds of first-time user and measure whether the promised work actually gets done.

For a developer-focused public release, compare the audiences and formats in [DevHunt vs Product Hunt](https://zeroraised.com/blog/devhunt-vs-product-hunt).

## Frequently asked questions

### How do I publish a Slack app?

Choose the right distribution route, implement OAuth for more than one workspace, test installation and removal outside the development workspace, prepare the required public pages and listing assets, then submit a production-ready app for review if you want a Slack Marketplace listing.

### Does a Slack app have to be in the Slack Marketplace?

No. An app can remain attached to one workspace or use unlisted public distribution. Apps intended for commercial distribution should follow Slack's current Marketplace guidance and review process.

### What does Slack review before Marketplace publication?

Slack reviews suitability, functionality, security, permissions, user experience, onboarding, app pages and listing information, and reviewers need a working installation path plus any credentials required to test the service.

### What pages does a Slack Marketplace app need?

Prepare a public app landing page, a public support page with an account-free contact route, and a clear privacy policy covering collection, use, retention and data requests.

### What should I measure after publishing a Slack app?

Record completed installations, successful setup, the first useful in-Slack action, repeated use, errors, support requests and removals, split by release source where possible.