getCheckout() works on Wix dev site but fails on production app instance

Ask the community
, , ,
1

Hi,

I’m developing a custom Wix CLI app for a Foxpost pickup-point selector on the Wix Checkout page.

The app works correctly on my Wix development site, but the same app logic fails on the production site.

On production, the checkout Site Plugin loads correctly and the frontend successfully calls my Wix-managed backend endpoint:

/api/foxpost-point?checkoutId=...

The request includes a Wix Authorization header and reaches the backend, but the backend returns:

HTTP 502
{"error":"C02"}

The C02 error is generated by my own error handling when the backend getCheckout() call fails, so unfortunately the original Wix error is currently hidden.

I have already verified the following:

  • The production checkoutId is valid. I queried the same checkout directly through the Wix eCommerce Get Checkout API and it was returned successfully.
  • The checkout is active and belongs to the expected production site.
  • FOXPOST is the selected delivery option.
  • The frontend Site Plugin loads correctly on production.
  • The request from the Site Plugin reaches the backend with an Authorization header.
  • The failure happens specifically when the backend tries to retrieve the checkout.
  • The app configuration currently requests the relevant eCommerce permissions, including Read checkout data, Read and manage checkout data, and Stores permissions.
  • The application works on the Wix development site but fails on the live site.
  • Reinstalling/removing the app on production is being tested to rule out an app-instance permission issue.

The flow is essentially:

Checkout Site Plugin
        ↓
authenticated request
        ↓
/api/foxpost-point
        ↓
Wix getCheckout(checkoutId)
        ↓
fails only on production

One additional difference I found between the development and production checkout configuration is that the development site contains two Site Plugin custom elements:

9b6b761a-2de6-480e-a1f5-17630de1e6fc
tagName: foxpost-picker

399cb7b1-d1c9-4b48-9286-d3a67b529a1d
tagName: foxpost-elso-lepes

while the production checkout only contained foxpost-picker.

However, I checked the source of the second element and it is effectively an empty/legacy element, so I do not currently believe that it causes the getCheckout() failure.

My main questions are:

  1. Can a Wix development-site app instance have different effective API permissions/authentication behavior from the same app installed on a production site?
  2. For a Wix-managed CLI backend endpoint called from a Checkout Site Plugin, does getCheckout() need to be wrapped in auth.elevate()?
  3. Is there a supported way to inspect the actually granted permissions/scopes of a specific production app instance, rather than only the permissions configured in the app dashboard?
  4. Is there a way to see the original Wix API error generated inside a Wix-managed backend endpoint when the SDK call fails?
  5. Are development-site app instances given any elevated/test permissions automatically that production instances do not receive?

The interesting part is that the exact production checkout ID can be retrieved successfully when calling the Wix eCommerce API with an authorized site context, but the same checkout retrieval fails from inside the installed app’s production backend request.

Any guidance on the authentication context of Wix CLI backend endpoints / Checkout Site Plugins would be greatly appreciated.

Thanks!

2

This pattern (works under your own dev-site session, fails for the installed production app instance) usually comes down to elevation, not an actual outage on getCheckout itself. A few things worth checking:

  1. Wrap the backend getCheckout(checkoutId) call in auth.elevate(). Retrieving checkout/business data through an app-installed identity needs elevated permissions in the SDK, without it the docs say you’d expect a 403, but your own C02 wrapper could be swallowing that and re-surfacing it as a generic 502.
  2. Before your C02 handler catches the failure, log the raw error object (message, details, cause), not just the boolean. That tells you if it’s really a 403 permission error vs. something else (rate limit, a malformed checkoutId, etc) that just happens to only show up in the production context.
  3. Your dev site session runs under your own Wix account, which already has broad access. That’s a different auth context than a visitor hitting the live Checkout Site Plugin on production, where the request only carries whatever your app’s installed instance was actually granted at install time, not necessarily what’s configured in the dashboard right now. If you added the eCommerce scopes after the app was first installed on production, the existing instance token may predate them, worth confirming the reinstall test you mentioned actually clears that.
  4. Also worth ruling out: make sure the backend is using the elevated/app SDK context for this call and not accidentally the member/visitor context, that mismatch is the single most common cause of exactly this dev-works/prod-fails split.

If the raw error from step 2 isn’t a 403, come back with it and I’ll take another look.

If this helped, please mark it as Solved.