Summary
Our automated publish to Microsoft Edge Add-ons fails at the package upload step with HTTP 403, status message Client ID is Invalid, using the Client ID displayed on our Partner Center Publish API page together with a freshly generated API key from the same page. The failure is reproducible with raw curl (no SDK, no CI involved), so it is not a tooling or environment problem on our side.
Additionally, we cannot reach any Microsoft support channel to report this (details below), which is why we are filing it here.
Environment
- Extension: Lean Library (published on the Edge Add-ons store)
- Product ID:
6e6dxxxx-xxxx-xxxx-xxxx-xxxxxxxxd0eb
- Client ID:
7203xxxx-xxxx-xxxx-xxxx-xxxxxxxx7d49
- API key: generated on 2026-08-12 on the Publish API page, ends in
…1!DQ
- Endpoint:
POST https://api.addons.microsoftedge.microsoft.com/v1/products/{productId}/submissions/draft/package
- Auth per docs:
Authorization: ApiKey <key> + X-ClientID: <clientId>
- Normally published via CI (CircleCI + axios); reproduced independently with curl
Steps to reproduce
curl -v -o /dev/null \
-X POST "https://api.addons.microsoftedge.microsoft.com/v1/products/<PRODUCT_ID>/submissions/draft/package" \
-H "Authorization: ApiKey <API_KEY>" \
-H "X-ClientID: <CLIENT_ID>" \
-H "Content-Type: application/zip" \
--data-binary @extension-package.zip
Expected
202 Accepted with an operation ID in the Location header.
Actual
< HTTP/1.1 403 Client ID is Invalid
< Content-Length: 0
< Request-Context: appId=cid-v1:23f44029-850d-47f4-8c9f-200d01ff4866
< Date: Wed, 12 Aug 2026 11:53:35 GMT
What we have ruled out
- Stale/mismatched values: header values were verified byte-for-byte on the machine making the request (correct lengths - 36-char Client ID, 40-char key - hex-dumped, no hidden characters or trailing whitespace).
- Copy errors: the API key was regenerated and the Client ID re-copied from the same Publish API page in the same session; the failure persists.
- Propagation delay: the 403 persists well beyond any reasonable propagation window after key generation.
- Tooling: reproduced with raw
curl outside our CI, from a clean network with no proxy (TLS certificate verified as Microsoft's).
- Account mismatch: the credentials and the extension are under the same Partner Center account; the product is visible in that account's Edge overview.
The Client ID shown on our Publish API page is rejected identically to a nonexistent one, while the API key itself appears to be accepted (a deliberately bogus key produces a different error), which isolates the failure to the Client ID lookup on the service side.
Impact
We are unable to publish updates of our extension to the Edge Add-ons store via the Publish API. This blocks our production release.
Support channels are inaccessible to our account
We attempted to raise this through official channels first, without success:
- The support request form (
https://support.microsoft.com/supportrequestform/e7a381be-9c9a-fafb-ed76-262bc93fd9e4) redirects our business account (the one that owns the extension) to the Engage Center, which shows "No Access".
- In Partner Center, the Contact support button is disabled, the Help icon is not shown for our account, and the AI assistant does not support the Edge workspace.
This looks like a second, separate Partner Center problem, and it leaves GitHub as our
only working channel.
We are happy to share the full Client ID, product ID, and exact timestamps through a
private channel on request.
Summary
Our automated publish to Microsoft Edge Add-ons fails at the package upload step with HTTP 403, status message
Client ID is Invalid, using the Client ID displayed on our Partner Center Publish API page together with a freshly generated API key from the same page. The failure is reproducible with rawcurl(no SDK, no CI involved), so it is not a tooling or environment problem on our side.Additionally, we cannot reach any Microsoft support channel to report this (details below), which is why we are filing it here.
Environment
6e6dxxxx-xxxx-xxxx-xxxx-xxxxxxxxd0eb7203xxxx-xxxx-xxxx-xxxx-xxxxxxxx7d49…1!DQPOST https://api.addons.microsoftedge.microsoft.com/v1/products/{productId}/submissions/draft/packageAuthorization: ApiKey <key>+X-ClientID: <clientId>Steps to reproduce
Expected
202 Acceptedwith an operation ID in theLocationheader.Actual
What we have ruled out
curloutside our CI, from a clean network with no proxy (TLS certificate verified as Microsoft's).The Client ID shown on our Publish API page is rejected identically to a nonexistent one, while the API key itself appears to be accepted (a deliberately bogus key produces a different error), which isolates the failure to the Client ID lookup on the service side.
Impact
We are unable to publish updates of our extension to the Edge Add-ons store via the Publish API. This blocks our production release.
Support channels are inaccessible to our account
We attempted to raise this through official channels first, without success:
https://support.microsoft.com/supportrequestform/e7a381be-9c9a-fafb-ed76-262bc93fd9e4) redirects our business account (the one that owns the extension) to the Engage Center, which shows "No Access".This looks like a second, separate Partner Center problem, and it leaves GitHub as our
only working channel.
We are happy to share the full Client ID, product ID, and exact timestamps through a
private channel on request.