I’m running into an issue after the recent WeWeb update (the new editor domain changes like *-editor.weweb.io), and I’d like to check if anyone else is experiencing the same.
Since the update, all my API calls to Xano stopped working in the WeWeb editor. Before that, everything was working perfectly.
Here’s what I observed:
Direct requests (via curl/Postman) to my Xano endpoints work fine
Requests from WeWeb fail
The error appears as a generic “Network Error” or CORS-related issue
It happens across multiple endpoints (not just auth)
What I’ve already tried:
Configured CORS in Xano (origins, headers, methods, credentials, etc.)
Tested with wildcard and explicit headers
Verified endpoints and API groups
Tested both custom domain and direct Xano URL
Confirmed that the API itself is working correctly
Important detail:
Simple GET requests without preflight work, but anything triggered from WeWeb (which includes preflight/headers) fails.
This makes me suspect something changed in how WeWeb handles:
headers (X-Data-Source, X-Branch)
preflight requests
or datasource/plugin behavior after the update
Is anyone else experiencing issues with Xano after the recent WeWeb update?Or is there anything new regarding CORS / headers / plugin behavior that we should be aware of?
Any help or confirmation would be really appreciated
Some users have the same issue as you. On our side we can’t reproduce the issue for now, we are investigating. If you could help us to understand it would be amazing
In your Xano API group, did you define CORS rules? Could you share screenshots of the default and custom tab?
If you prefer to share privately, you can send a message to the support and we will help you
I’m getting the following alert: “Sorry, new users can only put one embedded media item in a post.”
Because of this limitation, I’ll split my response and send one screenshot per reply so I can share all the necessary details.
Here are the screenshots of my current CORS configuration (default and custom tabs).
It’s probably not necessary, but since I had already tried several approaches and wasn’t sure what else to test, I ended up trying it this way as well.
I’ve now removed it and tested again, but the same error still persists.
I also removed all origin and header configurations and ran new tests, but with no success.
After that, I unchecked all HTTP methods (GET, POST, etc.) and tested again — still no change.
I ran into the same editor-login issue and in my case it was caused by a CORS allowlist mismatch after WeWeb changed the editor origin for my project.
What changed on my side was the editor host moved from *.weweb-preview.io to *.editor.weweb.io. My live app still worked, but editor-mode auth requests started failing because Xano was still only allowing the old origin.
The fix was to update the Xano CORS settings to include the new editor origin for the project. After adding the new https://<project>-editor.weweb.io origin, editor login started working again.
So if your live app works but editor login/current-user fetch is failing, I would check whether the request origin changed and whether your backend CORS allowlist still matches the current WeWeb editor origin.
Thank you very much for the detail of how you fixed your issue Randy! If you can let us know @AgentePro if it’s fixing your issue also on your side
If not, could you please send a message to the support, we will talk with you in a direct chat, it will be much easier to help you and understand why you have this issue
In the screenshots I posted earlier, you can see that the editor URL you mentioned (https://<project>-editor.weweb.io) is already included in my CORS configuration, so it seems this might not be the root cause in my case.
I also re-did all the steps and configurations, leaving only this specific editor URL in the allowlist, and the error still persists.
Additionally, I created a brand new API group and a new endpoint with no CORS configuration at all, and it still isn’t found when I try to fetch it from WeWeb.
@Mael I’ll reach out via support as well to help investigate this further
Shot in the dark here and In the project link you put in your CORS setting in xano double check….is there a “/“ after the .io by chance at the end of your project link that was entered into your CORS? I’ve noticed sometimes when I copy the link directly from the browser in my editor into the CORS settings in xano it adds a “/“ at the end of the project link. If yours did take it out
I have a test branch that I use in the editor and a live branch for production. The WeWeb → Xano plugin was actually using the CORS configuration from the live branch, which is why none of the changes I was making in my test branch had any effect.
As soon as I updated the CORS configuration directly in the live branch and added the new editor URL, everything started working immediately.
From my perspective, this feels like a confusing behavior (or a bug), because my plugin configuration is set to use the test branch, so I expected CORS to be taken from there.
Anyway, it’s working now. Thanks a lot to everyone who helped.
I found a bug with Xano Auth plugin. I configured the global headers and bound a header to a global variable, which value I toggle to change between “live” and “test” data sources.
This approach works fine inside the editor, but in the deployed project only (ONLY) with “ME” endpoint the variable value always gets stuck on either “test” or “live”, and doesn’t change despite the toggle switch.
This is the response I got:
Hi Batik, our team has not been able to find the resources to prioritize this one yet. We will take a look when we have more time.
I assume it was never resolved. And as I see it now the bug also persists inside Xano Data Source plugin.
