> ## Documentation Index
> Fetch the complete documentation index at: https://extension.js.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Publish to the browser stores

> The full store journey for a browser extension: register store accounts, get API credentials, configure the project, author STORE.md, submit, track review, and handle rejections.

Shipping an extension to the Chrome Web Store, Firefox Add-ons, and Edge Add-ons is one journey with the same shape on every store: register a developer account, create the listing once, get API credentials, and automate every submission after that. This page walks the whole journey. The packaging page names the archive each store takes, and the per-store guides cover each credential portal in detail:

* [Package an extension for store upload](/docs/publishing/package-for-the-stores)
* [Get your Chrome Web Store credentials](/docs/publishing/chrome-credentials)
* [Get your Firefox Add-ons credentials](/docs/publishing/firefox-credentials)
* [Get your Edge Add-ons credentials](/docs/publishing/edge-credentials)

## The journey

<Steps>
  <Step title="Register the store accounts">
    Each store requires a developer account before anything else works. See
    [account prerequisites](#account-prerequisites) below for the fee,
    agreement, and enrollment each store demands.
  </Step>

  <Step title="Create each listing once by hand">
    The Chrome and Edge APIs cannot create a new listing. Upload the first zip
    manually in the store dashboard. That first upload is what creates the
    extension ID (Chrome) and the Product ID (Edge) that automation needs.
    Firefox can create a new unlisted add-on through the API; a listed add-on
    still needs a first manual submission.
  </Step>

  <Step title="Get API credentials per store">
    Follow the per-store guides linked above. Each guide names the exact portal
    page, shows what every value looks like, and lists the expiry rules.
  </Step>

  <Step title="Enter the credentials">
    Set the environment variables in your own CI, or keep them in a
    `.env.submit` file you write yourself. Keep it out of git.
  </Step>

  <Step title="Author STORE.md">
    Write the [STORE.md metadata file](/docs/workflows/store-metadata) before
    the first submission. Submission tooling reads it and attaches reviewer
    notes, release notes, and certification notes automatically. Without it,
    submissions go out noteless.
  </Step>

  <Step title="Submit">
    Submit from your own CI against each store's API. Dry-run first when your
    tooling supports it: a dry run verifies credentials and zips without
    uploading anything.
  </Step>

  <Step title="Track the review">
    A successful submission means the store accepted the upload and queued it
    for review. Review is a third-party decision: poll each store's dashboard
    or API for status, and never claim a listing is live before the store
    confirms it.
  </Step>

  <Step title="Handle a rejection">
    Read the failure reason the store returned, fix the cause, and record both
    in the version history section of `STORE.md` so the next submission does not
    repeat the mistake. Vague permission justifications are the most common
    rejection on every store.
  </Step>
</Steps>

## Account prerequisites

| Store | Account | Cost | Before automation works |
| - | - | - | - |
| Chrome Web Store | [Developer Dashboard](https://chrome.google.com/webstore/devconsole) registration | One-time \$5 | Upload the first zip manually in the dashboard. The API cannot create a new item, and the extension ID only exists afterwards. |
| Firefox Add-ons | [AMO](https://addons.mozilla.org) developer account plus the Firefox Add-on Distribution Agreement | Free | Accept the agreement. The API key page stays locked until you do. |
| Edge Add-ons | [Partner Center](https://partner.microsoft.com/dashboard/microsoftedge/overview) enrollment in the Microsoft Edge program | Free | Create the product with a first manual submission. There is no create-product API, and automation requires the Product ID. |

## Where credentials live

You hold the credentials yourself. A `.env.submit` file is the usual
per-project credential file: one per repository, kept out of git, backed by
your own secret storage. In CI, store each value as a secret.

Keep credentials per project even when two projects share a store account.
All three stores' API credentials are account-wide, so a separate publisher
account per product line is the only real isolation boundary on the store
side. Rotating a credential then touches exactly one project.

## What a submission needs, per store

| Store | Secrets | Identifiers | Store-specific rules |
| - | - | - | - |
| Chrome | OAuth client ID, client secret, and refresh token, or one service account JSON | Extension ID, publisher ID | First upload is manual. Listing copy is dashboard-only: the API accepts no metadata. |
| Firefox | JWT issuer and JWT secret | Add-on GUID (required for the listed channel) | New add-ons must declare `data_collection_permissions` in the manifest. |
| Edge | Client ID and API key | Product ID (always required) | The product must already exist in Partner Center. |

## Next steps

* Build the archive each store takes:
  [Package an extension for store upload](/docs/publishing/package-for-the-stores).
* Get credentials: [Chrome](/docs/publishing/chrome-credentials),
  [Firefox](/docs/publishing/firefox-credentials),
  [Edge](/docs/publishing/edge-credentials).
* Write the paperwork once:
  [Store metadata in one STORE.md file](/docs/workflows/store-metadata).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.