ExtensionOpsFree release scan

Release engineering / migration guide

Chrome Web Store API V1 to V2 migration checklist

Google says Chrome Web Store Publish API V1 is supported only until October 15, 2026. If your extension publishing script still calls the old API, inspect the active CI path before the next release.

Updated October 9, 2026 · Based on Google's public API documentation.

Check your repository before changing production

ExtensionOps offers a free static public-repository scan for supported release risks. It reports file-level evidence; it does not execute repository code or guarantee store approval.

Scan a public GitHub repository — free

The endpoints changed

V1 uses the `www.googleapis.com` endpoint with `/chromewebstore/v1.1/` paths. V2 uses the `chromewebstore.googleapis.com` service and publisher-scoped item resources. Treat these as examples; check the current API reference for request bodies and authentication.

V1 upload — deprecated

PUT https://www.googleapis.com/upload/chromewebstore/v1.1/items/EXTENSION_ID

V2 upload

POST https://chromewebstore.googleapis.com/upload/v2/publishers/PUBLISHER_ID/items/EXTENSION_ID:upload

V1 publish — deprecated

POST https://www.googleapis.com/chromewebstore/v1.1/items/EXTENSION_ID/publish

V2 publish

POST https://chromewebstore.googleapis.com/v2/publishers/PUBLISHER_ID/items/EXTENSION_ID:publish

Six checks before your next extension release

  1. 01

    Find V1 endpoints in release code

    Search scripts, workflow YAML, shared CI libraries and store-publishing dependencies for chromewebstore/v1.1. Check which files are actually invoked by your current release workflow.

  2. 02

    Resolve the V2 publisher resource

    V2 identifies each item as publishers/{publisherId}/items/{itemId}. Confirm the correct publisher and extension IDs for stable, beta and test listings.

  3. 03

    Update upload and publish operations

    Migrate the URL, HTTP method and request handling together; V2 upload and publish are distinct operations. Do not assume a changed x-goog-api-version header converts a V1 URL to V2.

  4. 04

    Preserve release-channel behavior

    Check existing visibility settings, review timing, staged publishing and rollout percentages before changing the CI script. A successful upload is not equivalent to approval or publication.

  5. 05

    Validate with a disposable release path

    Run your normal build and test steps, inspect the final zip and manifest, then exercise the publishing integration with a safe test item where your process permits. Keep store credentials in your own environment.

  6. 06

    Record evidence and remove the old dependency

    Capture the tested commit, exact script path, review state and CI result. Rescan to confirm no active V1 endpoints remain, and keep build, browser testing and store review as separate checks.

Reference documentation

The exact remediation depends on how your project authenticates, packages extensions, chooses release channels and handles store responses. Do not change production publishing scripts without validating those behaviors.

Free public release scan →Fix and monitoring optionsSecurity model