> ## Documentation Index
> Fetch the complete documentation index at: https://xanots.docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Lovable

> Install the Xano connector in Lovable so its agent authors a XanoTS backend and deploys it with a short-lived credential minted through the connector.

[Lovable](https://lovable.dev) builds your frontend; the **Xano connector** gives the same
agent a backend. With it installed, Lovable already knows this project's backend is authored
as XanoTS — tables, APIs, functions, triggers — and can ship it with `npx xanots deploy`.

Two things come from the connector, and they are what make the flow work:

* **Lovable preloads the XanoTS knowledge files** into the agent's context, so it knows XanoTS
  exists and reaches for it rather than Supabase or Lovable Cloud.
* **Lovable's connector gateway holds your Xano OAuth token** and injects it when the agent
  mints a CLI credential. The agent never sees that token, and there is no key to paste.

<Note>
  Using **Bolt** instead? It has no connector gateway, so the same capability arrives over MCP
  with an explicit tool surface — see [Bolt](/connectors/bolt).
</Note>

## Install the connector

<Steps>
  <Step title="Add Xano from Lovable's integrations">
    Find **Xano** in Lovable's connector list and install it into your project.
  </Step>

  <Step title="Authorize">
    Sign in to Xano and approve the connection. The connector represents your authenticated
    Xano account, and the instance and workspace you pick are what every later deploy is
    bound to. Reconnect to target a different workspace.
  </Step>

  <Step title="Check it took">
    Ask the agent which Xano account it is connected to. It has one permitted diagnostic —
    `GET /api:meta/auth/me` — which distinguishes "the connector is not authorized" from
    "Xano is unreachable".
  </Step>
</Steps>

## How a deploy runs

The agent authors your backend as XanoTS defs, then mints a credential immediately before
running the CLI:

```
agent: (authors xano/index.ts)
agent: POST /api:meta/xanots/cli-token  → through the connector; the gateway adds OAuth
agent: npx xanots deploy …              → runs with the credential as env vars
```

The mint returns three values, which map onto the CLI's three environment variables:

| Response field | Environment variable |
| -------------- | -------------------- |
| `instance_url` | `XANO_INSTANCE_URL`  |
| `workspace_id` | `XANO_WORKSPACE_ID`  |
| `token`        | `XANO_META_TOKEN`    |

```bash theme={null}
XANO_INSTANCE_URL="https://xare-rvr8-mnnt.xano.io" \
XANO_WORKSPACE_ID="165" \
XANO_META_TOKEN="<the minted token>" \
  npx xanots deploy ./xano/index.ts
```

`XANO_META_TOKEN` is the secret, and it is short-lived by design — **600 seconds** by
default. It is passed to that one process and discarded: never written to `.env`, project
source, Git,
**or Lovable project secrets**. A run that fails on authentication is fixed by minting again,
not by asking for a longer lifetime. (`ttl` requests a different one, in seconds, clamped to
60–3600; `expires_in` reports what was actually granted.)

`instance_url` and `workspace_id` are not secrets and are safe to write into project
configuration.

<Warning>
  The connector's own **OAuth access token** is never the agent's to handle. It must not
  retrieve, inspect, or supply it, or assemble the mint request by hand with one — the whole
  point of the gateway is that it injects the credential for you.
</Warning>

### The CLI is the only way in

Exactly two Xano endpoints are called through the connector — `xanots/cli-token` to mint the
credential, and `auth/me` as a diagnostic. **Everything else goes through the XanoTS CLI**: no
direct meta-API calls to list objects, read schema, create tables, or apply changes.

That is not ceremony. A change made through a direct API call is not described by your
XanoTS source, so the next deploy overwrites it or conflicts with it. The CLI is what keeps
the code the source of truth.

For the same reason, a failed mint is a stop, not a puzzle. The agent is told to report the
status and body rather than retry variations of the path, probe other endpoints, or fall back
to another way of getting a Xano credential — a failure there means the connector is not
authorized, and that needs you.

### Ephemeral by default

A deploy goes to an [ephemeral
environment](/guides/deploying#deploy-targets-and-what-a-release-changes) unless you say
otherwise — a disposable environment, created or refreshed on each run, with its own URL and
its own database, expiring on its own. Nothing that already exists is touched.

| You say                                    | Target                             | Command          |
| ------------------------------------------ | ---------------------------------- | ---------------- |
| "deploy", "try it", or nothing about where | Ephemeral                          | `xanots deploy`  |
| "release", "go live", "my real workspace"  | The workspace you chose at connect | `xanots release` |

A release **merges into your real workspace and overwrites what is live there**, so it should
only ever happen because you asked for it. Watch for a `package.json` script named `deploy`
that actually performs a release — that is not the right default for "just deploy this".

### Pointing the frontend at the backend

Lovable serves the frontend itself, so nothing injects `window.XANO_HOST` the way [Xano's own
static hosting](/guides/deploying#wiring-the-frontend-to-the-backend) does. Set the backend
URL as a build-time environment variable in the Lovable project — on a Vite frontend:

```
VITE_XANO_HOST=https://xare-rvr8-mnnt.xano.io/tenant/abc123
```

XanoTS frontends resolve the host in this order, so the variable is used when the injected
global is absent:

```ts theme={null}
const HOST = (typeof window !== "undefined" && window.XANO_HOST) || import.meta.env.VITE_XANO_HOST;
```

<Warning>
  An ephemeral environment answers **only** at its tenant-scoped URL —
  `https://<instance>.xano.io/tenant/<name>`, including the `/tenant/<name>` segment. Take it
  verbatim from what the CLI printed for that deploy, not from `instance_url`; the bare instance
  URL reaches a different environment or 404s. A release is the other case — there the backend
  answers at `instance_url` itself, which is stable across releases.
</Warning>

Stored files have the same trap: a file column's own `url` addresses the instance host
without the tenant segment. Build file URLs from the file's `path` and the same `HOST` —
`fileUrl(row.avatar, HOST)` from `@xanots/sdk`. See
[The typed frontend surface](/guides/typed-frontend).

## When something fails

| Symptom                                                                 | What it usually means                                                                                                        |
| ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| The agent reports an authentication failure from the CLI                | The credential expired between minting and running. Mint again and retry once.                                               |
| The mint itself fails                                                   | The connector is not authorized. Reinstall or reconnect it; the agent is told to stop rather than work around this.          |
| API calls from the deployed frontend 404, or hit the Lovable dev server | `XANO_HOST` is unset, empty, or missing its `/tenant/<name>` segment. Confirm it is set for the build, not just locally.     |
| The CLI fails on your code                                              | The SDK indexes its own errors in `node_modules/@xanots/sdk/llms/errors.md`. Fix the def, mint a fresh credential, redeploy. |
| The agent starts building a backend somewhere else                      | Say so — it should not swap XanoTS for another backend because a deploy failed.                                              |