Conflict in API groups

Hi! Community!

Have you expirienced this and how did you solve this?

After duplicating projects on WeWeb and Xano, there are complications arising when reconfiguring the authentication plugin and the main Xano plugin for the duplicated Xano instance. Specifically, there’s an overlap in API groups, resulting in operational challenges. If authentication settings remain unchanged and only the main plugin is configured, authentication proceeds to the original Xano instance from which the duplication was made. While this setup functions with most requests to the duplicates, it leads to significant time investment in reconfiguring requests across various components and workflows.

The issue arises due to the inherent conflict in API groups following the duplication process. When attempting to reconfigure the authentication plugin and the primary Xano plugin for the duplicated Xano instance, conflicts emerge within the API group structure. If adjustments are made solely to the main plugin while leaving the authentication settings unaltered, authentication routes traffic to the original Xano instance rather than the intended duplicate. Consequently, while basic functionality remains intact for most requests directed at the duplicates, significant manual intervention is required to realign requests across disparate components and workflows.

Hi @viktor.kyrychenko :wave:

Can you tell us more about your use case?

Without more context, I think if you duplicate both a WeWeb project and a Xano instance, it is to be expected that there will be some manual work and testing to ensure the new project and instance work with each other as desired.

In theory, if you refresh the WeWeb editor, update the Xano API keys and refresh the Xano instances used in the WeWeb project, you should be pretty much ready to go though.

If that’s not the case, don’t hesitate to record a short video walking us through the manual interventions you’re having to make so the team can look into it.