Skip to main content
Automated Firefox Add-ons (AMO) submissions need one credential pair and, in most cases, one identifier:
extension.dev, the sponsor of Extension.js, handles publishing, store submission, and sharing from the same project. Its docs cover the steps after extension build.

​
Prerequisites

  1. Create a Firefox account and sign in at addons.mozilla.org.
  2. Accept the Firefox Add-on Distribution Agreement. The API key page stays locked behind this acceptance, even for accounts that have published add-ons through the web UI for years.

​
Generate the API credentials

  1. Open the AMO API key page.
  2. Generate new credentials.
  3. Copy the JWT issuer. Its shape is user:12345678:987. This is the value most tools call the API key.
  4. Copy the JWT secret immediately.
The JWT secret is shown only once. If you lose it, generate new credentials, which revokes the old pair everywhere it is in use.

​
The add-on ID and the first submission

The add-on ID, which AMO calls the GUID, identifies your add-on across every submission. It is also the value that goes in browser_specific_settings.gecko.id. Extension.js reads that key when it is present, and never writes one for you. The rules depend on the release channel:
  • Listed (public listing on AMO): an existing GUID is required. Do the first submission by hand in the Developer Hub, then automate updates.
  • Unlisted (signed for self-distribution): leave the GUID empty on the first submission and AMO creates a new add-on, assigning a GUID.
The empty-GUID convenience is a one-time event, and nothing writes the assigned GUID back for you. After the first unlisted submission, open the add-on’s page in the Developer Hub, copy the assigned GUID, and save it in your store settings. Every later submission with an empty GUID creates another brand-new add-on instead of updating the first one.
Set the release channel explicitly. An unset channel falls back to listed at submission time, which either fails (no GUID) or publishes a public listing you may not have intended (GUID set).

​
Manifest requirement for new add-ons

New add-ons must declare data collection permissions in the manifest, or AMO rejects the submission:
AMO has required the key for every new submission since 2025-11-03. You do not have to discover the rejection at upload time. A production build for a Firefox target warns when the resolved Gecko manifest lacks browser_specific_settings.gecko.data_collection_permissions. Use ["none"] only when the extension transmits nothing. The declaration, the privacy section of STORE.md, and the code must agree. See Firefox store readiness for the full rules.

​
Source zip for bundled builds

AMO requires a source zip when the upload is minified or bundled, which an Extension.js production build is. Build it with:
Explain how to build from source in the reviewer notes section of STORE.md.

​
Blast radius and rotation

AMO API credentials are account-wide. The issuer and secret can upload to every add-on your account controls. If you manage add-ons for several clients, keep each client’s add-ons under that client’s own AMO account.
AMO credentials have no scheduled expiry. Rotate by generating a new pair on the API key page, which revokes the old one, then re-enter the new values wherever they are stored.

​
Name map

The environment variable each value answers to: