The embedded script that could never have worked
The first attempt at replacing Wix’s discount text used an embedded script. The reasoning was sound: a site plugin renders in a sandboxed frame, so it cannot restyle Wix’s own markup or sit inside it. An embedded script runs on the page itself and can.
That reasoning is correct. The approach is still dead, for a reason no amount of fixing the script addresses.
The app’s backend is not publicly callable. Every path on the app host — a
real endpoint, a route that does not exist, even / — returns 500 with an
empty body when requested without a Wix app-instance context. A plain fetch
from the shop’s page has no such context. So an embedded script can never
read anything from this app: not a styling value, not a price, not whether a
discount exists at all.
It fails silently, too, which is what turns a dead end into a wasted week. The script treats a non-OK response as “nothing to show”, so the page renders exactly as Wix built it and nothing anywhere reports a problem.
There was a second symptom we never fully explained. Across many releases, a consent-category change and a site publish, the embedded script was not injected into the page at all. The page carried no trace of it while registering every custom element correctly.
Custom elements do not have this problem. Wix serves them from the same host with an access token injected, and the SDK inside them carries the instance. That is the only route from a storefront to the app’s own backend.
The capability was never the problem. The direction of the call was.