Zoho Creator Widget Cutoff: Change the Host, Keep V1 or V2

AorBorC point of view: Change the host now; plan any V1-to-V2 Widget JS API migration separately.

Zoho has issued a final notice for developers and partners using widgets in Zoho Creator applications. Support for the older Widget JS API CDN URLs was originally due to end in June. Zoho extended the deadline to July 31, 2026, and says widgets that are not updated will stop functioning correctly once support for the old URLs is discontinued.

Only deployed widgets that still load one of Zoho’s old js.zohostatic.com URLs are affected by this cutoff. Creator applications without widgets, and widgets already loading the current static.zohocdn.com URL for their existing V1 or V2 version, are outside this specific change.

A Creator widget is a packaged custom interface placed inside an application page. Its CDN URL is the web address that loads Zoho’s JavaScript library, which lets the widget work with Creator data and other supported application behavior. Depending on the Widget JS API version, implementation, and user permissions, that can include record operations and other application tasks.

The edit can be small. The release still needs evidence: inspect the package that corresponds to the uploaded widget, preserve V1 or V2, replace the host, re-upload the package, and test the critical action with representative users and permissions.

Confirm whether your widget is affected

Zoho’s notice identifies two old Widget JS API URLs and their replacements.

V1:

Old: https://js.zohostatic.com/creator/widgets/version/1.0/widgetsdk-min.js
New: https://static.zohocdn.com/creator/widgets/version/1.0/widgetsdk-min.js

V2:

Old: https://js.zohostatic.com/creator/widgets/version/2.0/widgetsdk-min.js
New: https://static.zohocdn.com/creator/widgets/version/2.0/widgetsdk-min.js

If the exact build artifact for an uploaded widget contains neither old URL, document it as unaffected and stop this cutoff workflow for that widget. Do not manufacture a migration project where this specific dependency is already current.

Change the host, not the version

The version segment matters. Zoho’s current documentation recommends V2, but V1 and V2 are different contracts. V1 is based on Creator REST API V2 and requires SDK initialization. V2 is based on REST API V2.1 and exposes a broader task set.

The July 31 action is a CDN reference change. Changing the host and the Widget JS API version in one hurried release expands the test surface and makes a failure harder to diagnose.

The CDN script reference sits in the widget ZIP’s HTML. The modified widget file must be re-uploaded for the deployed widget to use it; changing a repository or local copy alone does not update the uploaded artifact.

First contain the deadline by keeping V1 as V1 or V2 as V2. After that release is stable, decide separately whether a V1 widget should move to V2, whether its permissions remain appropriate, and whether its business logic needs stronger tests or redesign.

Test the uploaded ZIP, not just the repository

The operational risk is not knowing which uploaded packages still contain the old URL.

Teams may have widgets spread across several Creator applications, workspaces, pages, published access paths, archived repositories, and packages maintained by former employees or outside vendors. A search in the current repository can miss the build artifact that corresponds to the uploaded widget. A successful page load can also miss a broken button, upload, lookup, or record update that appears only for a particular permission set.

The Widget JS API documentation makes the possible impact concrete. For V2, Zoho documents Data, Publish, File, Meta, and Util API tasks; V1 supports a smaller subset. API-call success also depends on the permissions assigned to the user accessing the widget in the target application.

That means the test plan should follow business actions, not only browser rendering.

These are examples of where widgets can be used, not a claim that every affected widget controls those processes. The practical question is narrower: what business action does each deployed widget support, and what evidence will show that action still works after the package is updated?

Minimum release checklist

Use this checklist before the old Widget JS API URLs are discontinued.

1. Confirm scope from the uploaded artifact. Inventory applications with widgets, rank state-changing workflows first, and obtain the exact source or build artifact corresponding to each uploaded widget. Search HTML, source, generated output, minified assets, templates, and copied packages for both old URLs. If neither appears, record the widget as unaffected and stop.
2. Record the release context. For each affected widget, note its business owner, application and page, current V1 or V2 version, initialization, supported tasks in use, critical action, users, and permission sets.
3. Keep the last working package. Retain the previous ZIP, source revision, package hash or version, and last known working test as the rollback point.
4. Change only the host. Preserve /version/1.0/ or /version/2.0/, rebuild where required, and re-upload the modified widget file.
5. Capture loading evidence. Confirm the browser requests static.zohocdn.com, no old-host request remains, and no new console or network error appears. For V1, confirm ZOHO.CREATOR.init() completes. Check content-security, proxy, firewall, and domain allowlists where they apply, and rule out a cached old library.
6. Prove the critical action and permissions. Test the supported actions the widget really uses with representative users and permission sets, including published access without a Creator account where relevant. Prefer tagged test records in non-production. If live testing is unavoidable, use reversible actions, capture before and after state, and name the cleanup owner.
7. Reconcile a connected outcome where relevant. Retain source and destination record IDs and statuses. In a safe test path, prove one intended business outcome is created and that the workflow’s defined retry behavior does not create a duplicate.
8. Log the release. Record the tester, evidence, approver, upload time, success result, rollback decision, remaining vendor-owned or V1 widgets, and a post-deadline smoke check.

What this fix does not solve: risks and limits

• Zoho does not specify a cutoff time zone or promise that every affected widget will fail in the same way. Complete and verify the change before July 31 rather than planning around an assumed hour.
• Even if an old URL still responds during the grace period, that does not establish readiness after support is discontinued.
• A host replacement does not convert V1 to V2. That migration needs its own syntax, initialization, parameter, permission, and regression review.
• A repository search can miss generated, copied, or vendor-maintained packages. Reconcile the source with the uploaded widget and ask outside maintainers for written confirmation.
• A new host does not repair weak permissions, brittle JavaScript, missing error handling, or an unreconciled business process. Zoho describes the new CDN infrastructure as faster and more reliable, but that is not a measurable performance promise for a specific application, network, or region.

Where the hype is not useful

This is not a reason to rebuild every Creator application or rush every V1 widget onto V2 before the deadline.

It is a precise dependency change with a precise affected scope. Fix and verify that dependency first. Then decide whether any widget separately needs a V2 migration, better permissions, stronger tests, or redesign.

How AorBorC would handle it

AorBorC would run this as a scoped Creator rescue and release audit.

Start with the uploaded packages and the people who use them. Build a widget-to-workflow register, preserve the existing Widget JS API version, replace the required reference, and test the highest-consequence action first. Record the owner, package version, expected state change, test permissions, evidence, approver, and rollback file.

Human review still matters. An automated test can prove that a request completed and a record changed. A workflow owner should confirm that the right record changed, the resulting business state makes sense, and the receiving system agrees.

That approach fits AorBorC’s founder-led Zoho and custom-app work: practical implementation, QEngine-assisted regression coverage where it adds value, integration discipline, rescue credibility, and systems designed to survive future changes instead of only passing today’s demo.

For direct help, Zoho Creator development covers widget and application ownership, Zoho integrations covers connected-system handoffs, and Zoho QEngine implementation can support repeatable permission and workflow regression coverage.

Business takeaway

Before July 31, prove three things for every affected widget: the uploaded package no longer calls the old host, its existing V1 or V2 version completes the critical action for the expected permissions, and any connected outcome reconciles.

That turns a small dependency change into a controlled release and leaves behind the package inventory the next platform change will need.

Your next move

Bring one affected widget package, its application page, V1 or V2 version, user permissions, and critical action to Plan your project. The useful outcome is concrete: an affected-widget inventory, a same-version host fix, permission-based test evidence, and a rollback point.