Choose how to use Xano

WeWeb can work with Xano in three ways. Before you build tables and workflows, pick the one that matches your project: it decides where your requests run, and how Xano knows who the user is.

The three setups

Setup	Flow	Best when
Xano is your backend	Browser → Xano	Your data, your logic, and your sign in already live in Xano
Xano is a data source	Browser → WeWeb server → Xano	WeWeb builds your backend, and Xano is one of the places your data comes from
Hybrid	Both	Xano is your backend, and you also use WeWeb API Endpoints or tables fetched by the WeWeb server

Two settings follow from this choice:

• The Fetch all views via the frontend (advanced) toggle when you create a Xano table. When it's on, the browser retrieves the data from Xano directly. When it's off, your WeWeb server retrieves it. Learn more about Xano tables →
• Where you put your API Request actions: in Interface workflows (they run in the browser), or in backend workflows such as API Endpoints (they run on your WeWeb server).

Xano is your backend

In this setup, your app talks to Xano straight from the browser. This is the most common setup if you built your backend in Xano before using WeWeb.

• Keep Fetch all views via the frontend (advanced) on for your Xano tables. It's on by default.
• Call Xano from Interface workflows with the API Request action.
• Set Xano as your Authentication System to sign users in with your own Xano endpoints. Learn how to sign users in with Xano →

Once a user is signed in, WeWeb sends their Xano session with every request to Xano. You don't need to add an Authorization header yourself.

XANO PROTECTS YOUR DATA

In this setup, nothing sits between the browser and Xano. Make sure every endpoint that returns private data requires authentication in Xano.

Xano is a data source

In this setup, WeWeb is your backend, and Xano is one of your data sources, like Airtable or Google Sheets. Your WeWeb server calls Xano, and your app only talks to your WeWeb server.

• Turn off Fetch all views via the frontend (advanced) when you create your Xano tables.
• Call Xano from backend workflows, for example an API Endpoint. When you create an API Endpoint, you can start from the Request Xano API template: it calls a Xano endpoint and returns its response, or an error response if the call fails.
• Protect access in WeWeb, with the Security settings of your tables and API Endpoints.

When your WeWeb server calls Xano, there is no signed-in Xano user. Xano has to accept the request on its own terms:

• The endpoint is public in Xano.
• Or you send a key that Xano checks, in the Headers of the table or the Custom Headers of the action. Store that key in an environment variable instead of typing it in the field.

Hybrid

In this setup, Xano is your backend and signs your users in, and you also use WeWeb backend workflows or tables fetched by your WeWeb server. Those need to know who the user is too.

To make it work:

1. Set Xano as your Authentication System.
2. Create an app workflow on the On user load trigger that retrieves the user from Xano and ends with Set User. This sets the user in your interface.
3. Create a backend workflow on the same On user load trigger that does the same thing. This sets the user for your backend workflows and table views, so their Security settings can check that the user is signed in.

Without the backend workflow, your WeWeb server treats every request as signed out, even when the user has a valid Xano session.

Learn how to set up the On user load workflows →

CONTINUE LEARNING

Now that you know which setup you're building, create your first table on top of a Xano endpoint.

Xano as a data source →