Before moving a Chrome extension’s release pipeline to Web Store API V2, inventory every script and dependency that still calls V1, then map its request and response handling. Google’s current V1 reference says support ends on October 15, 2026. A status lookup is a useful first check, but it does not prove that uploading or publishing works.
The deadline applies to the publishing API, not a blanket shutdown of existing extensions. Google announced V2 on October 15, 2025; this is a migration reminder checked on October 11, 2026 (KST), not a new launch. See the V1 deprecation notice and official migration announcement.
Find the caller before changing the pipeline
Start with a read-only review of the repository and the release configuration you are authorized to inspect. Search for chromewebstore/v1.1, older upload URLs and the names of extension-publishing packages. Include shared CI templates and reusable workflows: a clean application repository does not prove that its imported publishing action has migrated.
Record the package version actually selected by the lockfile or action reference, rather than the newest version shown on a project homepage. Follow the wrapper to the endpoint it uses. If that implementation is unavailable, mark it unknown and assign an owner. An absence of literal V1 strings is inconclusive when a dependency constructs the URL.
Make one row for each release operation
Use this original inventory before proposing a change. The evidence column should point to a file, line, dependency version or sanitized observation. Do not paste access tokens, authorization headers or private package contents into the worksheet.
| Operation | Where it runs | Evidence to capture | Open question |
|---|---|---|---|
| Status lookup | Script or wrapper + version | Current endpoint and fields read | Which revision does the check describe? |
| Package upload | Release job + owner | HTTP method, artifact source, response parser | What proves processing finished? |
| Publish request | Job or manual step | Requested behavior and response handling | Does review lead to staging or publication? |
| New item / visibility | Existing setup process | Current operator and dashboard handoff | Who performs the non-API step? |
A hypothetical row might read: “Upload — release workflow using package version X — wrapper source still uses a V1 PUT — maintainer must confirm a V2-compatible release.” That is a finding to resolve, not proof that the extension has failed or that upgrading the package is safe.
Map method, target and response separately
Google’s migration table maps item retrieval to V2 :fetchStatus, updating an item to :upload, and publishing to :publish. The upload mapping changes from PUT to POST. V2 resource paths identify both publisher and extension. Treat each mapping as a small contract review rather than a global URL replacement. The announcement’s endpoint table is the starting reference; inspect the current method documentation before implementation.
For each caller, compare four things: which item it targets, what it sends, which response fields it consumes, and what it does next. A script that exits successfully because it received HTTP 200 can still be checking the wrong revision or skipping an unfinished step. Keep the desired release behavior written beside the code change so that a migration does not accidentally change when users receive an update.
Keep upload, review and publication evidence apart
The V2 fetchStatus reference describes separate published and submitted revision status fields alongside upload state. Some revision fields can be unset, and the last asynchronous upload state is supplied only for an asynchronous upload within the past 24 hours. Do not treat an absent field as a failure by itself. Preserve those distinctions in your release record. “There is a published revision” does not establish that the package from today’s build is that revision.
Before a separately authorized release test, write its acceptance criteria. Identify the expected extension, package version, intended publish behavior and the evidence that will confirm each stage. Afterward, record the observed revision and time instead of reusing one green “success” flag for the whole pipeline. Unknown status values should remain unresolved until checked against the current documentation and client behavior; they are not a reason to continue automatically.
A read-only status request can help establish that the configured identity reaches the intended item. It cannot exercise package processing, review or release. This guide has not run a migration or a live publishing test, and it does not supply a command that uploads or publishes an extension.
Close the handoff before the support deadline
V2 does not provide API operations for creating a new item or changing an item’s visibility; Google directs those needs to the Developer Dashboard. Put the human owner in the migration record rather than dropping the step. V2 also supports staged publication, so confirm the intended release behavior explicitly instead of assuming every successful submission should immediately reach users. These boundaries are documented in the V2 announcement.
- List every discovered caller, including wrappers, with evidence and an owner.
- Resolve unknown endpoint versions and document the planned V2 mapping.
- Review response handling and the separation between uploaded, submitted and published revisions.
- Assign dashboard-only work and a separately approved test window.
- Keep the old pipeline from being mistaken for a working fallback after V1 support ends.
The useful output today is a complete migration inventory with unresolved questions visible. A successful deployment of your extension requires its own observed evidence. Recheck the official support notice before scheduling the work; do not infer an exact shutdown hour from a date-only announcement.