Firefox Add-ons

Firefox submissions go through the AMO API v5. The flow is create an upload, poll its validation, then create the version from it. The platform runs it with the project's stored credentials; trigger it from the console's Stores tab, from an agent with extension_submit, or with POST /api/cli/stores/submit. See Publishing.

Credentials

AMO authenticates with a JWT signed from an issuer and secret. The platform mints the JWT per request with a 30 second expiry, so the secret never travels and a captured token dies fast.

Value	Secret	Notes
API key (issuer)	STORE_FIREFOX_API_KEY	From the AMO API credentials page
API secret	STORE_FIREFOX_API_SECRET	Shown once, at creation

Add them from Stores, New, Firefox in the console.

Submitting

Submit from the Stores tab, or over the API:

curl -s -X POST https://www.extension.dev/api/cli/stores/submit \
  -H "Authorization: Bearer $EXTENSION_DEV_TOKEN" \
  -d '{"browsers":["firefox"],"buildSha":"<sha>","channel":"stable"}'

Listed and unlisted

AMO has its own channel concept, separate from Extension.dev release channels. The AMO channel is a project store setting.

AMO channel	Result
listed	Published on addons.mozilla.org, goes through review
unlisted	Signed and returned to you, not listed publicly

unlisted is how to get a signed build for self distribution without a public listing.

The first submission

A first submission cannot be listed without an existing add-on GUID. It either goes unlisted or creates a new add-on. When AMO assigns the GUID, the platform persists it back to the project automatically, so the second submission already knows its add-on.

Source code uploads

AMO requires a source archive when the submitted build is minified or otherwise not readable, which is true of most bundled extensions. Attach the source archive to the submission in the project's Firefox store settings.

Without it, review of a bundled extension is rejected for unreviewable code.

Data collection consent

Firefox enforces declared data collection. An add-on that collects data without declaring it in the manifest is rejected. Declare it before submitting, per the data collection permissions documentation on Extension Workshop.

Reviewer and release notes

Firefox reviewer notes and release notes are read from STORE.md in the project root and submitted automatically. See Publishing.

Watching

The Stores tab follows the submission to a terminal state: in_review, processing, published, rejected, failed. The same status returns from GET /api/projects/{id}/stores/status. Firefox tracks by the version id the submission returns.

When it fails

• Validation failures surface while the upload is polled, before a version exists. Read the validation messages; the version was never created.
• A first submission that asks for listed is blocked by design. Submit unlisted or let it create the add-on, then go listed once the GUID exists.
• The preflight, dryRun on the submit call, reports credential health and the console page that fixes a blocked store.

Last verified against AMO API v5 on 2026-07-27. Submission outcomes are subject to Firefox Add-ons review and policy.

Next

• Publishing overview for STORE.md and dry runs
• HTTP API for the submit and status endpoints