# UNUSED IMAGES
Source: https://docs.xano.com/UNUSED_IMAGES
# Unused Images Audit
**Branch:** `audit/unused-images`
**Date:** 2026-03-31
**Total images:** 1,361
**Unused images:** 258
**Space recoverable:** \~82 MB
## Method
Searched all `.mdx`, `.md`, `.json`, `.html`, `.tsx`, `.ts`, `.jsx`, `.js`, `.css`, `.yaml`, and `.yml` files for references to each image filename (including URL-encoded variants with `%20`, `%28`, `%29`). Images listed below had zero matches.
## Garbage / Broken Filenames (3 files)
These appear to be corrupted filenames (likely from a bad paste or import):
* ` 
* `a.svg`
* `b.svg`
* `c.svg`
* `d.svg`
* `asdasd.mp4`
* `asdasd.webm`
* `templates-${2amt2}-${ramn2}.png`
## CleanShot Screenshots (14 files)
Likely uploaded screenshots that were never embedded in docs (includes files only referenced in deprecated `xanoscript-old/`):
* `CleanShot 2025-03-07 at 08.29.54 (1).png`
* `CleanShot 2025-03-10 at 08.02.32.png` *(only in deprecated `xanoscript-old/`)*
* `CleanShot 2025-03-10 at 08.08.53.png` *(only in deprecated `xanoscript-old/`)*
* `CleanShot 2025-03-11 at 09.52.58.gif` *(only in deprecated `xanoscript-old/`)*
* `CleanShot 2025-03-11 at 09.52.58.mp4`
* `CleanShot 2025-03-11 at 09.52.58.webm`
* `CleanShot 2025-03-11 at 09.54.26.png` *(only in deprecated `xanoscript-old/`)*
* `CleanShot 2025-03-11 at 09.57.55 (1).png` *(only in deprecated `xanoscript-old/`)*
* `CleanShot 2025-03-11 at 09.59.34.png` *(only in deprecated `xanoscript-old/`)*
* `CleanShot 2025-03-11 at 15.44.48.gif` *(only in deprecated `xanoscript-old/`)*
* `CleanShot 2025-03-11 at 15.44.48.mp4`
* `CleanShot 2025-03-11 at 15.44.48.webm`
* `CleanShot 2025-03-11 at 15.46.24.png` *(only in deprecated `xanoscript-old/`)*
* `CleanShot 2025-03-11 at 16.23.04.png`
## Generic "image" Files (15 files)
* `image.gif`
* `image.mp4`
* `image.webm`
* `image (1).mp4` / `image (1).png` / `image (1).webm`
* `image (2).mp4` / `image (2).png` / `image (2).webm`
* `image (3).gif` / `image (3).mp4` / `image (3).png` / `image (3).webm`
* `image (4).gif` / `image (4).mp4` / `image (4).webm`
* `image (5).mp4` / `image (5).webm`
* `image (85).png` *(only in deprecated `xanoscript-old/`)*
* `image (86).png` *(only in deprecated `xanoscript-old/`)*
## Named But Unused Images (54 files)
These have descriptive names but no references in the codebase:
* `apis-20251001-153843.png`
* `apis-20251001-153913.png`
* `apis-20251001-153935.png`
* `apis-20251001-154307.png`
* `before-you-begin.png`
* `branching-and-merging-20250925-211239.png`
* `branching-and-merging-20250925-212047.png`
* `branching-and-merging-20250925-212105.png`
* `branching-and-merging-20250925-212215.png`
* `branching-and-merging-20250925-213916.png`
* `branching-and-merging-20250925-214009.png`
* `branching-and-merging-20250925-214035.png`
* `branching-and-merging-20251019-105642.png`
* `community.png`
* `custom-functions-20251013-183429.png`
* `dev-life-cycle.png`
* `docuBadge (11).png`
* `external-api-request-20251212-143041.png`
* `external-api-request-20251212-145146.png`
* `faq.png`
* `function-stack-20251008-145218.png`
* `function-stack-20251008-145615.png`
* `function-stack-20251008-145656.png`
* `function-stack-20251008-150642.png`
* `function-stack-20251008-150855.png`
* `function-stack-20251008-151134.png`
* `function-stack-20251008-151249.png`
* `function-stack-20251008-151352.png`
* `functionstack-drag.gif`
* `functionstack-drag.mp4`
* `getting-started-ai-20260119-171910.png`
* `getting-started-ai-20260119-172009.png`
* `getting-started-code-20260112-101535.png`
* `getting-started-visual-20260108-181454.png`
* `getting-started-visual-20260108-181655.png`
* `index-20251013-143803.png`
* `index-20251013-143820.png`
* `index-20260115-172822.png`
* `index2-20251009-181022.png`
* `index2-20251009-181237.png`
* `index2-20251009-181641.png`
* `introduction-20251002-122823.png`
* `middleware-20251014-113625.png`
* `officehours.png`
* `the-database.png`
* `the-visual-builder.png`
* `visualcanvas-mininav.gif` / `visualcanvas-mininav.mp4`
* `visualcanvas-navigating.gif` / `visualcanvas-navigating.mp4`
* `visualcanvas-nodes.gif` / `visualcanvas-nodes.mp4`
* `visualcanvas-zooming.gif` / `visualcanvas-zooming.mp4`
* `visually-20251008-160939.png`
* `where-should-i-start-20251001-134828.png`
* `where-should-i-start-20251001-134957.png`
* `workspace-20251014-122101.png`
* `workspace-20251014-122144.png`
* `xano-ai-assistants.png`
* `youtube.png`
* `YT2.png`
## UUID-Named Unused Images (97 files)
Hash-named images with no references:
* `011dccc0-image.jpeg`
* `0224f83c-image.jpeg`
* `03538981-image.jpeg`
* `03d18500-image.jpeg`
* `052bb0ce-image.jpeg`
* `05c4d553-image.jpeg`
* `06ad3245-image.jpeg`
* `07b5b542-image.jpeg`
* `07e30696-image.jpeg`
* `08191502-image.jpeg`
* `091a61a6-image.jpeg`
* `09e6c75d-image.jpeg`
* `0ab78f09-image.jpeg`
* `0ac806a3-image.jpeg`
* `0b01909c-image.jpeg`
* `0cd9ef02-image.jpeg`
* `0fddecf3-image.jpeg`
* `10c48f2e-image.jpeg`
* `11721c7f-image.jpeg`
* `11aaf707-image.jpeg`
* `13f40f45-image.jpeg`
* `18381f16-image.jpeg`
* `185962de-image.jpeg`
* `1bb09389-image.jpeg`
* `1d41b825-image.jpeg`
* `1e09bfeb-image.jpeg`
* `1f2d5e94-image.jpeg`
* `22f8a95f-image.jpeg`
* `235f7704-image.jpeg`
* `23772fab-image.jpeg`
* `23acb65a-image.jpeg`
* `241aeb90-image.jpeg`
* `2427a46f-image.jpeg`
* `24ef1999-image.jpeg`
* `268de66f-image.jpeg`
* `2e76023a-image.jpeg`
* `316ddc69-image.jpeg`
* `31f8c7d6-image.jpeg`
* `3217a5bd-image.jpeg`
* `38da8752-image.jpeg`
* `3aeb0424-image.jpeg`
* `3c0fb467-image.jpeg`
* `3dc7b9b4-image.jpeg`
* `3f85f1eb-image.jpeg`
* `3fd49f92-image.jpeg`
* `40ddf0f4-image.jpeg`
* `421215ff-image.jpeg`
* `4482fc67-image.jpeg`
* `4491fb41-image.jpeg`
* `45b5ba17-image.jpeg`
* `472aab63-image.jpeg`
* `472cbbc3-image.jpeg`
* `47674a30-image.jpeg`
* `48471be6-image.jpeg`
* `490ccf75-image.jpeg`
* `49e7c08c-image.jpeg`
* `4c559c1e-image.jpeg`
* `4e5cd9af-image.jpeg`
* `4f8458e4-image.jpeg`
* `54f26def-image.jpeg`
* `571afe25-image.jpeg`
* `582c405e-image.jpeg`
* `58e4e63e-image.jpeg`
* `5b0d7643-image.jpeg`
* `5d3db282-image.jpeg`
* `5d4812f7-image.jpeg`
* `5de2df3a-image.jpeg`
* `5df9f5f7-image.jpeg`
* `5f1e1c1b-image.jpeg`
* `6022fd52-image.jpeg` / `6022fd52-image.mp4` / `6022fd52-image.webm`
* `611a9cde-image.jpeg`
* `621819e5-image.jpeg`
* `674be43a-image.jpeg`
* `677a724a-image.jpeg`
* `6b1226ff-image.jpeg`
* `6b9cd6cd-image.jpeg`
* `6c82b2c7-image.jpeg`
* `6ed88a2c-image.jpeg`
* `71100e1a-image.jpeg`
* `726e546f-image.jpeg`
* `7c00c8b4-image.jpeg`
* `7c3c234f-image.jpeg`
* `7f0a9cea-image.jpeg`
* `819f325e-image.jpeg`
* `82cf8f12-image.jpeg`
* `8637d4e6-image.jpeg`
* `897ef275-image.jpeg`
* `8a4ba9c1-image.jpeg`
* `8c425bd8-image.jpeg`
* `90e90976-image.jpeg`
* `92b7c01b-image.jpeg`
* `937118e5-image.jpeg`
* `939176f1-image.jpeg`
* `9489d607-image.jpeg`
* `952b52c9-image.jpeg`
* `99d8ad8a-image.jpeg`
* `9b93391b-image.jpeg`
* `9ca99cc0-image.jpeg`
* `a0c3c830-image.jpeg`
* `a32bfc05-image.jpeg`
* `a6a34ee6-image.jpeg`
* `a6cbe5fc-image.jpeg`
* `aaab2177-image.jpeg`
* `abc0cbac-image.jpeg`
* `ac5ab1c5-image.jpeg`
* `af206ef1-image.jpeg`
* `af4a3465-image.jpeg`
* `b1d1ba3f-image.jpeg`
* `b53cc706-image.jpeg`
* `b5766935-image.jpeg`
* `b6abddd3-image.jpeg`
* `b74ed6da-image.jpeg`
* `b8a2d34d-image.jpeg`
* `ba9bf634-image.jpeg`
* `bdef672e-image.jpeg`
* `be1dd65c-image.jpeg`
* `be827eec-image.jpeg`
* `bf5e309c-image.jpeg`
* `bfed00e3-image.jpeg`
* `c100fd16-image.jpeg`
* `c3108fca-image.jpeg`
* `c4030f1b-image.jpeg`
* `c41e36a3-image.jpeg`
* `c42c8998-image.jpeg`
* `c7d7ab58-image.jpeg`
* `c892bab5-image.jpeg`
* `ca889728-image.jpeg`
* `cd39294a-image.jpeg`
* `ced19b02-image.jpeg`
* `cfe8dcd6-image.jpeg`
* `d4acf6cd-image.jpeg`
* `d50bb547-image.jpeg`
* `d998b56f-image.jpeg`
* `dbeafd11-image.jpeg` / `dbeafd11-image.mp4` / `dbeafd11-image.webm`
* `dc714d3a-image.jpeg`
* `df7f07f9-image.jpeg`
* `e71b2f05-image.jpeg`
* `e753d47c-image.jpeg`
* `e87ef769-image.jpeg`
* `e8b4f928-image.jpeg`
* `ecca42f1-image.jpeg`
* `ed941e80-image.jpeg`
* `edf15406-image.jpeg`
* `f219e47c-image.jpeg`
* `f24b47e9-image.jpeg`
* `f3f0d882-image.jpeg`
* `f5675125-image.jpeg`
* `ff5d1869-image.jpeg`
## To Delete All Unused Images
```bash theme={null}
# Review this list first, then run from repo root:
while IFS= read -r f; do rm "images/$f"; done < UNUSED_IMAGES_LIST.txt
```
# Agency Features
Source: https://docs.xano.com/agencies/agency-features
# Agency Dashboard
Source: https://docs.xano.com/agencies/agency-features/agency-dashboard
The Agency addon comes with Centralized Management so you can monitor and access your client instances, track commissions, invite new clients, and transfer ownership all from one interface.
If you have an Agency addon, Centralized Management is accessible under the Agencies you manage section.
Permissions and views may vary depending on the role your Agency admin defines for you.
## Accessing the Agency Dashboard
From the instance selection screen, click on the name of your agency, and choose Dashboard.
Click on the client instance to connect to it, or access their instance settings by clicking the⚙️ icon. From this screen, you can also get an overview of the client instance's usage and other metrics, giving you easy visibility into the current status.
# Agency Profile
Source: https://docs.xano.com/agencies/agency-features/agency-profile
As a Xano Agency, you are eligible to add your Agency profile to be listed on the [Xano Marketplace](https://xano.com/marketplace)'s Partner Directory. The Partner Directory is where Xano users and leads go to search for Xano partners to help with their projects.
The Agency profile is you and your agency's opportunity to make a lasting first impression and market your services to potential leads.
#### Eligibility
Only those a part of the Xano Partner Program may be eligible to have an Agency profile. Currently, an Agency plan initiates official Partner Program status and grants eligibility.
#### Leads
Leads will be able to contact your Agency through the Xano Marketplace to request your services on a Xano project.
Lead requests will come from **[leads@xano.com](mailto:leads@xano.com)**. Be sure to add this email address as a contact.
#### Types of Profiles
Agencies may list their services under the following categories:
* **Developer** - Generally, when an agency builds a project for a client.
* **Coach** - Generally, provides 1 on 1 or group coaching on Xano, lessons, courses, or similar services
* **Both Developer and Coach** - If your Agency provides both of the above services. Please detail both capabilities specifically in your agency profile.
## Create An Agency Profile
The Agency Profile is accessible from the Instance Menu Panel.
#### Required Information
Please be sure to include all the required information, you will not be able to submit your profile if you are missing any information.
* Agency Name
* Description - Please be detailed, this is an opportunity for you to tell leads why they should hire you.
* Contact Email - **This is the email address where lead requests will go to.**
* Location - The country your agency is based.
* Role - Service your agency provides: Developer, Coach, or both. ([See above](/agencies/agency-features/agency-profile#types-of-profiles) for more details).
* Website - Link to your agency's website.
* Video Link - A link to a video introducing your agency and services.
* Tools - No-code tools your agency is proficient in.
* Skills - Skills and capabilities that your agency has. (Examples: AI, Cryptocurrency, Healthcare, etc.) This section will be searchable by leads.
* Languages - Which languages your agency can conduct business in.
* Logo Image - Agency logo image for the profile.
* Banner Image - Agency banner image for the profile.
* Accepting New Clients - Whether or not your agency is accepting new clients.
After clicking save your Agency Profile will be submitted for review. Please allow up to a few days for your profile to be reviewed by the Xano team.
Once approved your profile will automatically appear on the Xano Marketplace [Partner Directory](https://dev.xano.com/marketplace/browse) and leads can start contacting you.
*The Xano team reserves the right to remove an Agency profile at their discretion.*
# Client Invite
Source: https://docs.xano.com/agencies/agency-features/client-invite
## Inviting a new client
You can invite a client that is new to Xano, or has an existing account already.
Our agency is called **Awesome Xano Agency**.
Click Invite Client
Let us know if this is a new Xano customer, if they have a current account and just need to upgrade their plan, or if they're an existing Xano customer already on a paid plan that will suit their needs.
By choosing New Xano Customer or Upgrade Xano Customer, you'll be able to let them know the plan that you recommend next. If you choose Existing Xano Customer, the invite will send right away.
Just select the plan they need and click Send Proposal to Client
## Tracking Client Invitations
On the Agency dashboard, you can track the status of your client invitations.
You can click on an invite to access more information, delete the invite, or resend it.
# Commission
Source: https://docs.xano.com/agencies/agency-features/commission
The Agency plan automatically enrolls you in the Xano Partner Program enabling you to earn commission on [client invites](/agencies/agency-features/client-invite).
Commissions can be viewed only by the owner of the Instance. Commissions are shown in the top right of the Client Dashboard:
### Agency Commission Stats
Agency stats show you commission information tied to your Agency plan. You can see the active client instances, subscriptions, client invoice history, (additional) credits, and payouts.
* Agency plans earn 20% commission on client invoices.
* To receive a payout, you must add your PayPal email address. (You can do this from your account page).
* Payouts require a minimum amount earned (this is typically \$100 but might depend on your Partner Program Agreement).
*Please note that the Xano Agency plan is a part of our *[*partner program*](https://www.xano.com/agency/)* and all commission payments are made via PayPal on the 1st & the 15th of each month.*
### Enterprise Accounts
When it comes to Enterprise accounts, commission structures can vary widely depending on the specific scenario. Unlike standardized commission rates for retail, individual accounts, or agency accounts, Enterprise accounts often involve more complex negotiations and tailored solutions, which can result in custom commission structures to the referring party. Please contact your Xano representative for any questions surrounding commission on an Enterprise account.
# Private Marketplace
Source: https://docs.xano.com/agencies/agency-features/private-marketplace
The Private Marketplace allows you to create Private Snippets exclusively for the clients of your Agency plan.
### Create a Private Snippet
To create a Private Snippet, navigate to the "Private" tab on the left menu and select your Agency's name. Then select Create Snippet in the top right corner.
Creating a Private Snippet has the same UI and experience as creating a regular, shareable [Snippet](/xano-features/snippets).
You can add as many API Endpoints as you want for a Private Snippet.
Review the included content, especially the database table and records. When a Snippet uses a database request, the associate database tables will be included. You may optionally include records along with the Snippet. **Be very careful not to share sensitive information**.
Once the Snippet is created, it will automatically be published for your clients.
### Managing the Private Marketplace
The Private Marketplace has two views from your Agency instance: Created Within Your Agency and Published Within Your Agency.
**Created Within Your Agency** shows all the Private Snippets that have been created within your Private Marketplace.
**Published Within Your Agency** shows all the Private Snippets that are available to be viewed and installed by your clients within the Private Marketplace.
#### Unpublish a Private Snippet
To unpublish Private Snippet, start on the Created Within Your Agency view and select the Snippet that you wish to manage.
Open the menu icon in the top right and select manage.
Unpublish the Snippet.
#### Create Update or re-Publish a Snippet.
When creating a Private Snippet, it is automatically published. If you unpublish a Private Snippet and later decide to publish it again, you do so by selecting Create Update.
Create Update also lets you make any changes and updates to an existing Snippet.
Once you select Create Update, the same experience as Create Snippet will be shown and you can make any changes to the Snippet and select Update.
### Client Install of a Private Snippet
To install a Private Snippet into a Client's Workspace, go to the Client's Instance and then select the desired Workspace to install it to.
The Agency who manages the Client Instance or the Client can perform this action.
Navigate to the Private tab on the left side and select the Published Within Agency tab.
Click on a Snippet you wish to install. You will first be prompted to "Get" the Snippet, which adds the Snippet Instance-wide. Once that action is performed, the Get button change to Install and it can be installed on the individual workspace.
Other workspaces on the Instance would be required to Install the Snippet in order to add it.
### Secure Share
Secure Share enables you to require a security token for the Snippet to be viewed externally.
Each token is only valid for a single installation. If you are going to share with multiple individuals, make sure to generate a unique link for each individual.
In order to securely share a Snippet, navigate to the Private Marketplace and select a Snippet from the Created Within Your Agency tab.
In the top right corner, select Secure Share.
Select Generate to generate a security token.
Once generated, a one-time use link will be generated with a unique security token. This link is good for a one-time use. You can copy it and send it securely for someone to use it once.
The landing page for a Secure Share and installation will be the same as a regular [Snippet](/xano-features/snippets).
# Transfer Ownership
Source: https://docs.xano.com/agencies/agency-features/transfer-ownership
## Transferring a Workspace to a Client Instance
From your instance selection screen, click
If you don't see your client's instance available, make sure they've accepted their [Client Invite](/agencies/agency-features/client-invite) and purchased the suggested plan.
This will create a **copy** of the workspace and transfer that copy to your client's instance.
You should proceed with any additional work by accessing the client's instance directly, as any further changes you make on your own copy of the workspace will not transfer.
For larger workspaces, transferring this way may not be possible. If you run into trouble, please reach out to support so we can process the migration for you.
# Xano For Agencies
Source: https://docs.xano.com/agencies/xano-for-agencies
The [Agency addon](https://xano.com/agency) is a unique offering specifically designed for development agencies and freelancers who are developing projects for clients.
#### Some of the unique features include:
* Easy client setup & handoff
* Centralized management
* Robust agency server setup
* Private “internal” marketplace
* Shared income - earn % commission for every new sign-up
* Xano partnership - eligible to receive “sourced” leads via Xano
* And more!
#### Read about the Agency plan:
* [Client Invite](/agencies/agency-features/client-invite) (Client Invite & Onboarding)
* [Transfer Ownership](/agencies/agency-features/transfer-ownership) (Transfer projects to clients)
* [Private Marketplace](/agencies/agency-features/private-marketplace)
* [Commission](/agencies/agency-features/commission)
# Knowledge
Source: https://docs.xano.com/agent-knowledge
Knowledge helps AI Agents understand your Xano workspace
Everything in Knowledge influences how AI agents build in this workspace, including the in-product Xano Agent and external AI coding agents like Claude, Codex, and others.
Agents read `AGENTS.md` on every run and reference docs and skills whenever a task calls for them. By curating Knowledge, you control what the agent understands, how it approaches work, and which rules it follows. Use the preview to see exactly how this context will appear to an agent.
Knowledge is valuable for solo builders and essential for teams. It helps ensure your backend is built and managed the way you expect when AI builders are involved, from high-level implementation strategy down to the detailed rules that define how specific logic should behave.
You can read a workspace's Knowledge from the command line with `xano knowledge list` and `xano knowledge get`. See [Knowledge commands in the CLI reference](/xano-cli/command-reference#xano-knowledge).
## AGENTS.md
If you're starting fresh with Knowledge, you should create your `AGENTS.md` first.
In the left-hand navigation, click Knowledge.
On the next screen, click Set up AGENTS.md.
Fill in the instructions for your build agents.
Knowledge only impacts all agents building *in* Xano, not agents you've built *using* Xano.
Specificity is fine, but you can (and should) also create separate docs and skills for specific object creation. Your agent will receive `AGENTS.md` with each prompt, and everything utilizes tokens, so efficiency is key to using Knowledge successfully.
* Good for AGENTS.md -- `Make sure all input names use camelCase.`
**Why?** Inputs are used across multiple different workflow types.
* Bad for AGENTS.md -- `For APIs, ensure that all input names are lowercase only. Also, for tasks, make sure that each scheduled run includes an audit at the beginning and at the end.`
**Why?** Specific instructions that only apply to single workflow types would be better suited for more specific skills that are only read when working on those workflows.
### What is this backend for?
A quick name for the backend. If you're not sure, just use the workspace name. Your agent will use this as context for the choices it makes.
### Any naming or data conventions?
These are rules related to how things like tables and APIs are named, or how your database columns are formatted. Here are some examples:
```bash theme={null}
Use snake_case for database table and field names.
Use camelCase for API response keys.
Status fields should use lowercase enum values, e.g. draft, published, archived, rejected.
```
### How does auth & security work?
This section dictates authentication and security practices for your backend. Here are some examples:
```bash theme={null}
All write actions require an authenticated user.
Public users may browse published posts only.
Only the owner user can edit their own posts.
Only admins can delete posts.
Use role-based checks for admin-only endpoints.
Never trust client-provided user_id; use the authenticated user's id.
```
### What should the agent never be doing?
Here, you can place anything else that you need the agent to follow, no matter what you're building. Examples are below.
```bash theme={null}
Never delete tables, fields, or existing production data without asking.
Never make draft posts publicly visible without asking.
Never modify payment, payout, or purchase logic without asking.
Never remove rate limits or abuse-prevention checks without asking.
Never create admin-only endpoints without access control.
```
Once you've saved your changes, you'll be taken to a split-screen view where you can continue to edit your `AGENTS.md` file, and also see an easy-to-read rendered version.
# Prompt Marketplace — Agent Context
AI Prompt Marketplace
## Conventions
* Use snake\_case for database table and field names.
* Use camelCase for API response keys.
* Prefix internal-only utility functions with util\_.
* Name user-facing API groups by feature area, e.g. prompts, creators, purchases, reviews.
* Use id for primary keys and \_id for foreign keys.
* Use created\_at and updated\_at timestamps on all persisted records.
* Status fields should use lowercase enum values, e.g. draft, published, archived, rejected.
* Money amounts are stored in cents as integers, e.g. price\_cents.
* Do not store derived totals unless they are needed for performance.
## Auth & security
* All marketplace write actions require an authenticated user.
* Public users may browse published prompts only.
* Only the prompt owner can edit, archive, or view draft prompts.
* Only admins can approve, reject, or feature prompts.
* Do not expose another user's email, payment details, or private profile fields.
* Validate all user-provided prompt content before publishing.
* Use role-based checks for admin-only endpoints.
* Purchases must be verified server-side before granting access.
* Never trust client-provided user\_id; use the authenticated user's id.
## Guardrails (do-not-touch)
* Never delete tables, fields, or existing production data without asking.
* Never change authentication logic without asking.
* Never make unpublished prompts publicly visible without asking.
* Never modify payment, payout, or purchase logic without asking.
* Never expose full prompt content to users who have not purchased it.
* Never remove rate limits or abuse-prevention checks without asking.
* Never create admin-only endpoints without access control.
* Never rename public API routes if existing clients may depend on them.
* Never store secrets, API keys, or credentials in database records.
* Never change pricing or revenue-share logic without confirmation.
### AGENTS.md settings
Once you've created `AGENTS.md` and returned to the Knowledge section, you can click on the on your `AGENTS.md` to change settings.
**Tags** are used to search across your workspace; so apply any tags you'd normally be searching for where you'd want `AGENTS.md` to be surfaced.
Not sure how to search? Press Cmd/Ctrl + K.
**Enforcement** is used to lock your AGENTS.md file, so it can not be modified or have its settings changed by anyone other than [workspace administrators](team-collaboration/role-based-access-control-rbac).
## Docs
Docs are used as reference materials; things like a brief on what your application does or information about your company.
An example of an appropriate doc could be a pricing plan reference, text from a company sales deck, or even notes on your target user base.
# ChatForge Pricing Plan Reference
This doc defines the available subscription plans, feature limits, and upgrade rules for ChatForge, a fictional AI chat product used for demo purposes.
Use this as reference material when building billing, permissions, onboarding, upgrade prompts, usage limits, or account settings features.
## Plans
### Starter
The Starter plan is for individuals trying ChatForge.
Limits:
* 1 workspace
* 50 AI conversations per month
* 5 saved prompts
* 1 connected knowledge source
* Community support only
* No team members
* No custom model settings
### Plus
The Plus plan is for individual power users.
Limits:
* 3 workspaces
* 1,000 AI conversations per month
* 100 saved prompts
* 10 connected knowledge sources
* Email support
* Custom model settings
* No team members
### Team
The Team plan is for small teams collaborating with AI.
Limits:
* 10 workspaces
* 10,000 AI conversations per month
* Unlimited saved prompts
* 100 connected knowledge sources
* Priority support
* Custom model settings
* Up to 25 team members
* Shared team prompt library
* Basic audit history
### Enterprise
The Enterprise plan is for organizations with advanced security and scale requirements.
Limits:
* Unlimited workspaces
* Custom conversation limits
* Unlimited saved prompts
* Unlimited connected knowledge sources
* Dedicated support
* Unlimited team members
* Shared team prompt library
* Advanced audit history
* SSO
* Custom data retention
* Custom contract terms
## Upgrade rules
Users should be prompted to upgrade when they attempt to exceed a plan limit.
Users should not lose access to existing conversations, prompts, or knowledge sources when they downgrade, but they may be prevented from creating new ones until usage is below the new plan limit.
Enterprise plan limits may be customized per customer.
## Feature access
Custom model settings are available on Plus, Team, and Enterprise.
Team members are available on Team and Enterprise.
Shared team prompt libraries are available on Team and Enterprise.
Basic audit history is available on Team.
Advanced audit history is available on Enterprise.
SSO is available on Enterprise only.
Custom data retention is available on Enterprise only.
Dedicated support is available on Enterprise only.
Click New doc or skill in the top-right corner.
Choose **Doc** from the dropdown. Give it a name, and set its inclusion mode.
**Inclusion Modes**
* **Always Included** -- Includes the whole doc in every agent request. Use this sparingly.
* **On Demand** -- The agent only gets the title and description up front, so it knows it exists and can intelligently utilize it.
* **Manual** -- The agent has no idea this exists unless you refer to it explicitly.
Once you've written your doc, click Save.
## Skills
Skills are used to give your agent more specific instructions during the build process, but don't necessarily need to be surfaced to the agent every time. An example of this would be `Make sure background tasks run no more than once per day, at 3:00am`.
Click New doc or skill in the top-right corner.
Choose **Skill**, fill in the name and apply some tags.
On the next screen, you'll get to define the skill itself.
### What does this skill do?
This will be provided to your agent with each request along with the skill title (if you choose on-demand inclusion). Keep it short and effective to inform the agent what this skill does.
Example: `Provides all required building conventions for background tasks`
### When should the agent use it?
This is provided when the agent actually invokes the skill; used to determine any conventions that should be followed to complete the requested task.
Example: `This should be used any time a user wants to create or edit a background task`
### First Steps
You can start writing your skill here, or just click Create Skill and navigate to the full editing experience.
### References
References are supporting files that the agent can load on demand as part of a skill. Using references is important to ensure that the main SKILL.md file doesn't become bloated and the agent can selectively retrieve only what it needs.
The line `If a background task calls for specific run logging, reference @run-logging.md for more details.` in the example skill below shows how you'd refer to a reference when creating your skills.
# Background Task Conventions
Use this skill when creating, editing, reviewing, or debugging background tasks, scheduled jobs, cron jobs, recurring workflows, queues, batch processing, or automated maintenance routines.
## Core rules
Background tasks should be conservative by default.
Do not create a high-frequency task unless the user explicitly asks for it.
Most recurring background tasks should run no more than once per day.
If a task processes user data, sends notifications, charges money, syncs external systems, deletes records, or changes account state, ask before making it recurring.
If a background task calls for specific run logging, reference @run-logging for more details.
## Default schedule conventions
Use these defaults unless the user specifies otherwise:
* Maintenance jobs: once per day
* Cleanup jobs: once per day
* Digest generation: once per day
* Analytics rollups: once per day
* Billing reconciliation: once per day
* External syncs: once per day
* Notification retries: use a capped retry strategy, not an unlimited schedule
Avoid running background tasks every minute or every few minutes unless the product requirement clearly depends on near-real-time behavior.
## Safety requirements
Every recurring task should have:
* A clear purpose
* A predictable schedule
* A maximum amount of work per run
* A way to avoid duplicate processing
* Error handling
* Logging
* A safe retry strategy
* A guard against running on records that are already complete
## Idempotency
Design background tasks so running the same task twice does not create duplicate records, duplicate emails, duplicate charges, duplicate notifications, or duplicate external API calls.
Use status fields, timestamps, job run records, or unique keys when needed.
## Batching
For tasks that may process many records, use batching.
Prefer small batches over processing an entire table at once.
Track progress when a job may need multiple runs to complete.
## External services
When calling external APIs from a background task:
* Respect provider rate limits
* Store the last successful sync time when useful
* Retry temporary failures
* Do not retry permanent failures forever
* Log enough detail to troubleshoot failures without storing secrets
## Notifications
Background tasks that send emails, push notifications, SMS messages, or webhooks must avoid duplicate sends.
Before sending, check whether the message has already been sent for the relevant user, record, and event.
## Deletion and cleanup
Prefer soft deletion, archiving, or marking records inactive over permanent deletion.
Ask before creating a task that permanently deletes user data.
Cleanup tasks should include a clear retention rule, such as “delete temporary files older than 30 days.”
## Ask before doing these
Ask before:
* Scheduling a task more than once per day
* Creating a task that sends messages to users
* Creating a task that charges money
* Creating a task that permanently deletes data
* Creating a task that syncs large amounts of external data
* Creating a task that changes user permissions or account state
* Creating a task with no clear stop condition or processing limit
# Background Task Run Logging Reference
Use this reference when building or editing a background task that needs to record its execution history.
The workspace already includes a `background_task_run` table. Use it to track when a task starts, whether it finishes successfully, how much work it performed, and any high-level errors that occurred.
## Existing table
Use the existing `background_task_run` table.
Expected fields:
```bash theme={null}
id
task_name
status
started_at
completed_at
records_checked
records_processed
records_failed
error_message
metadata
created_at
updated_at
```
Expected `status` values:
```bash theme={null}
running
completed
completed_with_errors
failed
skipped
```
Do not create a new run logging table unless the user explicitly asks for one.
## When to create a run record
Create a `background_task_run` record at the beginning of each scheduled task run.
Set:
```bash theme={null}
task_name = the stable name of the task
status = running
started_at = now
records_checked = 0
records_processed = 0
records_failed = 0
```
Use a stable `task_name` value that will not change if the task title is edited later.
## When to update the run record
Update the same `background_task_run` record when the task finishes.
For a successful run, set:
```bash theme={null}
status = completed
completed_at = now
records_checked = total records reviewed
records_processed = total records successfully processed
records_failed = 0
```
If the task finishes but some records fail, set:
```bash theme={null}
status = completed_with_errors
completed_at = now
records_checked = total records reviewed
records_processed = total records successfully processed
records_failed = total records that failed
error_message = short summary of the failure
```
If the task cannot complete, set:
```bash theme={null}
status = failed
completed_at = now
error_message = short summary of the failure
```
If the task has no eligible work to perform, set:
```bash theme={null}
status = skipped
completed_at = now
records_checked = 0
records_processed = 0
records_failed = 0
```
## Metadata
Use `metadata` only for task-specific operational details that help with debugging or safe continuation.
Appropriate metadata examples:
```bash theme={null}
last_processed_id
batch_size
sync_cursor
provider_name
dry_run
```
Do not store secrets, access tokens, API keys, passwords, payment details, or large raw API responses in `metadata`.
## Counting rules
Use these counting conventions consistently:
```bash theme={null}
records_checked = records the task evaluated
records_processed = records the task successfully changed or acted on
records_failed = records the task attempted but could not complete
```
Do not count skipped records as processed.
## Error messages
Keep `error_message` short and safe.
Good examples:
```bash theme={null}
3 records failed validation.
External provider returned a temporary error.
Task stopped because the configured batch size was reached.
```
Bad examples:
```bash theme={null}
Full API response body with sensitive data
Access token or authorization header
Full user record payload
Raw payment details
```
## Required task shape
When adding run logging to a background task, use this structure:
```bash theme={null}
1. Create a background_task_run record with status = running.
2. Store the run record id for later updates.
3. Process the task's eligible records.
4. Track checked, processed, and failed counts.
5. Update the same background_task_run record before the task ends.
```
Every background task that uses this reference should finish with exactly one final status:
```bash theme={null}
completed
completed_with_errors
failed
skipped
```
## Preview
Once you've populated your AGENTS.md and some docs / skills, you can preview what it all will look like to an agent by clicking Preview agent context in the top-right.
This is the context the agent receives at the start of every turn. Your AGENTS.md is shown in full; always-on skills are shown by their summary; on-demand items are listed by name so the agent can pull them in when relevant; and manual items load only when you name them in a prompt.
At the bottom of the modal, you can also see an estimate of potential token usage.
## Using Agent Knowledge
### In the Xano Agent
The Xano Agent is automatically presented with your knowledge in every session. You don't need to do anything; it already knows how to use it.
### In other AI coding agents
Knowledge is downloaded when running `xano workspace pull`, and your agent will likely pick up on this when working through your requests. However, to ensure consistency throughout each development session, you can instruct your agent to ensure that it refers to the knowledge present.
## What's next
See the in-product agent that reads your Knowledge on every build.
Connect external AI coding agents like Claude Code and Codex to your workspace.
Control who can edit or unlock enforced AGENTS.md files.
# Agents
Source: https://docs.xano.com/ai-tools/agents
Agents are used to perform 'fuzzy logic', or perform workflows that require intricate decision making, powered by an AI model of your choice
**Not looking for Agents, and just want to connect to your favorite AI models, like ChatGPT?**
**Check out this resource instead:** [Chatbots](/building-backend-features/chatbots)
**Quick Summary**
AI agents in Xano refer to autonomous entities designed to perform tasks by leveraging artificial intelligence. Your Xano Agents can integrate with your database, APIs, tasks, and functions, as well as external systems.
These agents can process data, make decisions, and execute actions without human intervention. AI agents in Xano can efficiently handle a variety of applications, from chatbots to data analysis tools, enhancing automation and productivity.
**Introduction to AI Agents**
**Tools for Agents & MCP Servers**
## What are Agents?
AI agents in Xano serve as integral components for building intelligent, automated systems as a part of your backend. These agents are designed to function autonomously, interacting with various elements of your app such as your APIs and database, as well as external systems, to streamline operations and enhance efficiency. AI agents can intelligently interpret inputs, process data, and deliver actionable outputs, all without the need for continuous human oversight.
Agents in Xano can leverage any of the most popular AI models once you provide an API key, such as:
* OpenAI
* Grok
* Anthropic / Claude
* Google Gemini
You can leverage the same visual builder you're used to using today to create workflows and functions that enable the agents to interact seamlessly with databases and external systems. With these foundational elements in place, AI agents can execute complex tasks, perform data analysis, or even serve as intelligent chatbots, making them versatile tools for a wide range of applications.
## Building Agents in Xano
1. From the sidebar, click Agents & MCP, then Agents
2. Click + Add Agent
3. Fill out the requested information
Please note that **not all models support certain features** such as:
* Structured outputs
* Reasoning
* Tool calls
In addition, some models may support individual features, but not **combinations of features**, such as:
* Structured outputs with tool calls
* Tool calls with reasoning
## All Agents
Give your agent a name that describes its role or primary function.
**Example:** `Order Processing Agent`
Internal-only field describing what your agent does.
**Example:** Analyzes incoming orders, decides on fulfillment priority, and triggers shipping workflows.
Define dynamic inputs the Agent can accept from Function Stack workflows and reference environment variables.
Use `{{ $args.propertyName }}` for workflow inputs and `{{ $env.variableName }}` for environment variables.
Select the AI model host for the agent.
**Options**
* Anthropic (Claude)
* OpenAI
* Google Gemini
Xano offers limited free Gemini credits for development.
Choose *Xano Test Model (Free Gemini Credits)* to use them.
Credits do not reset once used.
Define how many steps the Agent can execute to complete its task.
**Example:** `5`
Core instructions that define your Agent's role, capabilities, and behavior.
**Example**
> You are a helpful AI Agent that completes tasks accurately.
> When you need additional information to complete a task, use the available tools. Never make assumptions.
The type of prompt provided to the Agent.\
Either `messages` (a list of prior conversation messages) or `prompt` (a single standard prompt).
**Example:** `messages` or `prompt`
Additional context and instructions sent with each request.
**Example**
Please help the customer with their inquiry: `{{ $args.customer_message }}`.
Their account ID is `{{ $args.account_id }}`.
Configure the Agent to return responses in a specific JSON format using your predefined schema.
Toggle the checkbox to enable or disable.
Define the JSON structure for structured outputs.
**Example keys**
* `text`
* `user_email`
Categories for organizing your Agents.
**Example tags**
* `contact`
* `messaging`
Controls logging of requests to [Request History](/maintenance-monitoring-and-logging/request-history).
**Modes**
* **Inherit Settings:** Uses the currently defined workspace settings
* **Disabled:** No logs recorded
* **Enabled:** Logs requests with options for storage limits
## Anthropic Settings
Your Anthropic API key.\
Get your key here.
**Example:** `sk-ant-apixx-xxxxxxxxx-xxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxx`
The Anthropic model to use.\
List of available models here.
**Examples**
* `claude-opus-4-1-20250805`
* `claude-3-7-sonnet-latest`
Controls randomness of the response.
Higher values (e.g. `0.8`) make output more random;
lower values (e.g. `0.2`) make it more focused.
**Examples:** `0.1`, `0.9`
For reasoning models, when enabled, Claude creates `thinking` content blocks showing internal reasoning before the final response.
**Example:** Defaults to `true`
Enables extended thinking and specifies a thinking budget.\
More info here.
**Example JSON**
```json theme={null}
{
"type": "enabled",
"budget_tokens": 10000
}
```
## Google Generative AI (Gemini) Settings
Your Gemini API key.\
Get your key here.
**Example:** `AIzaSyDaGmWKa4JsXZ-HjGw7ISLn_3namBGewQe`
The Gemini model to use.\
List of available models here.
**Examples**
* `gemini-2.5-pro`
* `gemini-2.5-flash-lite`
Controls randomness of the response (creativity).\
Higher = more random, lower = more deterministic.\
More info here.
**Examples:** `0.1`, `0.9`
Grounding with Google Search connects Gemini to real-time web content and enables verifiable sources.\
Works with all available languages.\
Not all models support search grounding.\
More info here.
**Example:** `on` or `off`
Enables extended thinking and specifies a thinking budget.\
More info here.
**Example JSON**
```json theme={null}
{
"thinkingBudget": 1024
}
```
## OpenAI Settings
Your OpenAI API key.\
Get your key here.
**Example:** `sk-Am1rLw7xUwGxGuBasGsNt3BlbkFjdBgBUgBBK5BuG9y6oWWB`
The OpenAI model to use.\
List of available models here.
**Examples**
* `gpt-4.1-mini`
* `gpt-5`
Controls randomness of the response.
Higher values (e.g. `0.8`) make output more random;
lower values (e.g. `0.2`) make it more focused.
**Examples:** `0.1`, `0.9`
For reasoning models, sets how much effort the model spends thinking during generation.
**Examples:** `low`, `medium`, `high`
## Adding Tools to an Agent
An Agent needs tools to function — the tools are essentially single functions that the Agent can perform, such as looking up user data or cancelling a subscription.
1. From the sidebar, click Agents & MCP, then Tools
2. Click + Add Tool
3. Fill out the requested information
### Using Existing Function Stacks as Tools
In the existing function stack, click the ⋮ settings icon in the upper-right corner of another function stack, and click Use As AI Tool
Choose the Agent or MCP Server you'd like to add the tool to, and give it a name. This name is what the command will be, so make sure it's understandable
A new tool will be created in your chosen destination with a function to call the function stack. Xano will not make a copy of your existing function stack; instead, it will use a Run Endpoint function and call that function stack internally. This is ideal, so you only have to maintain one function stack.
Head to your tool's settings and add instructions. Instructions are important to have so the AI models and clients interacting with this tool understand how to use it.
### Creating Tools from Scratch
From the sidebar, click Agents & MCP, then Tools, then + Add Tool
Fill out the required information.
* **Name**
* Give your tool a recognizable name. This is also the command that will be used to execute your tool.
* **Description**
* This is an internal-only field just for you to describe the purpose of the tool.
* **Allow Connections**
* Enable or diffsable connection to this specific tool
* **Add Tag**
* Tag your tools for easier search across your Xano workspace
* **Authentication**
* Determine if this tool requires an authentication token
* **Tool Instructions**
* These instructions are what your clients will use to understand how to send requests to the tool, and what the expected result will be. Markdown format is recommended.
Build your tool's function stack. If you haven't already, make sure you're familiar with [Building with Visual Development](/building/visually)
Add the tool to an Agent or MCP Server. From the Agent or MCP Server, choose + Add Tool and select the tool you just created.
## Structured Outputs
Structured Outputs are used for providing a specific format that you need your agent to return its result as. This is especially useful when you are calling agents from other agents and want to ensure that the output from Agent 1 is clear and easy to understand for Agent 2.
You can add structured outputs to your Agent in the settings by checking the Structured Outputs checkbox, and then clicking **+ Add Output Schema** to build your output schema.
## Example Agents
### 🤖 Customer Support Agent
**Purpose**
This Agent is designed to handle customer inquiries that don't typically need human interaction.
**Tools**
An Agent designed for this purpose might have the following tools available:
* **Get User Information**
* Retrieves user information from the database
* **Update User Information**
* Retrieves existing user information from the database, and updates it per a user's request, such as changing their phone number or address
* **Send Verification Code**
* This tool could be used as a secondary security measure to verify that the request is coming from the user that the data belongs to
* **Change Subscription**
* Based on the user's request, this could be used to stop an upcoming renewal, or cancel a subscription immediately. Because Agents excel at 'fuzzy logic' depending on certain circumstances, this could also be used for things like churn prevention — dynamically offering the user a discount to stay, for example
* **Search Documentation**
* Calls an external API from your chosen documentation platform to search your product documentation in an attempt to solve the user's query without human intervention
* **Create Support Ticket**
* In the case that the Agent does not have the necessary tools to solve the user's concerns, create a support ticket for human intervention
### Agent Configuration
| Parameter Name | Purpose | Example |
| ------------------ | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | Give your agent a name that describes its role or primary function | Customer Support Agent |
| Description | Internal only field for describing what your agent does | Handles customer inquiries that don't typically need human interaction. Can retrieve user information, update accounts, send verification codes, manage subscriptions, search documentation, and escalate to human support when needed. |
| Agent Settings | Define dynamic inputs the Agent can accept from Function Stack workflows and reference environment variables | `{{ $args.customer_message }}`, `{{ $args.user_id }}`, `{{ $args.ticket_priority }}`, `{{ $env.SUPPORT_API_KEY }}` |
| Model Host | Select the AI model host for the agent | Claude Sonnet 4 |
| Max Steps | Define how many AI requests the Agent can execute to complete a task | 8 |
| System Prompt | The core instructions that define your Agent's role, capabilities, and behavior | You are a helpful Customer Support Agent that resolves customer inquiries efficiently. Always verify user identity before making account changes. Use available tools to gather information and resolve issues. If you cannot resolve an issue, create a support ticket for human intervention. Be polite, professional, and solution-oriented. |
| Prompt | Additional context and instructions sent with each request | Customer inquiry: `{{ $args.customer_message }}`. User ID: `{{ $args.user_id }}`. Account status: `{{ $args.account_status }}`. Please help resolve this customer's issue while following security protocols. |
| Structured Outputs | Configure your Agent to return responses in JSON format using structured outputs and your predefined schema | ✅ Enabled |
| Output Schema | Define the JSON structure for agent responses | response\_message, action\_taken, ticket\_created, follow\_up\_required |
| Tags | Categories for organizing your Agents | customer-service, support, automation |
| Request History | Controls logging of tool requests | Enabled: Logs requests with options for storage limits |
# Using OpenTelemetry with AI Agents
Source: https://docs.xano.com/ai-tools/agents/opentelemetry
Learn how to integrate OpenTelemetry with AI agents for enhanced observability and monitoring.
## What is OpenTelemetry?
Connect Xano agents to platforms like Langfuse, LangChain, or Braintrust to make your agent runs easier to understand and improve. After you add your API key, Xano will automatically send agent activity to your chosen tool so you can view run history, trace what happened step-by-step, spot failures or slowdowns, and iterate on prompts and workflows with more confidence.
## Which platforms are supported?
* [Langfuse](https://www.langfuse.com/)
* [LangChain](https://langchain.com/)
* [Braintrust](https://www.braintrust.dev/)
## Which one should I use?
The best choice is simply the one that fits how your team already builds and improves agents. If you’re already using one of these tools, start there. If not, pick the platform whose UI and workflow feel most natural for how you want to review runs, debug issues, and track improvements. And because the setup is just an API key, you can try one, see how it feels, and switch later in Xano with just a couple of clicks.
## Setting up the Integration
### Langfuse
[Langfuse](https://www.langfuse.com/) is an open-source observability platform designed specifically for AI applications. It provides tools to monitor, trace, and analyze the performance of AI agents, making it easier to identify bottlenecks and optimize their behavior.
In Langfuse, create an organization.
Create a new project within your organization.
From your project settings, click on "API Keys" -> "Create new API keys". The API keys created can only be viewed once, so make sure to copy them somewhere safe if you want to refer to them later.
In Xano, head to your agent, and click Setup OpenTelemetry Integration under the "Details" tab.
Check the Enable box, and fill in your secret key, public key, and base URL from Langfuse.
For future executions of your agent, you'll see metrics and traces being sent to Langfuse, where you can analyze them in detail.
### LangChain
[LangChain](https://langchain.com/) is a popular framework for building AI applications. It provides built-in support for OpenTelemetry, allowing developers to easily instrument their AI agents for observability.
Create a new project in LangChain, and generate an API key.
In Xano, head to your agent, and click Setup OpenTelemetry Integration under the "Details" tab.
Check the Enable box, and fill in your API key from LangChain.
For future executions of your agent, you'll see metrics and traces being sent to LangChain, where you can analyze them in detail.
### Braintrust
[Braintrust](https://www.braintrust.dev/) is another observability platform that supports OpenTelemetry for AI applications. It offers features like real-time monitoring, tracing, and alerting to help developers maintain the performance of their AI agents.
In Braintrust, create a new organization.
Choose **Trace an existing app**
Choose **OpenTelemetry** as your integration method and copy your API key.
In Xano, head to your agent, and click Setup OpenTelemetry Integration under the "Details" tab.
Select **Braintrust** from the dropdown, and fill in your API key and project name.
For future executions of your agent, you'll see metrics and traces being sent to Braintrust, where you can analyze them in detail.
# Templates
Source: https://docs.xano.com/ai-tools/agents/templates
Agent Templates
Install this snippet to monitor, analyze, and debug your agent’s behavior.
Gain critical insight into every agent run.
Install this snippet to manage and persist user interactions. The perfect
starting point for any chatbot or conversational agent.
## Agent History & Debugging Mode
Install this snippet to monitor, analyze, and debug your agent's behavior. Gain critical insight into every agent run.
* **Logging Database Tables**: Includes agents and agent\_runs, agent\_steps, agent\_tool\_calls tables to store detailed execution history.
* **Automated Logging Function**: A dedicated function to easily log the inputs, outputs, and steps of each agent run.
* **Monitoring Dashboard**: A utility API endpoint that provides a simple dashboard to review agent performance statistics and debug individual runs.
Monitors, analyzes, and debugs your agent’s behavior by logging every run, step, and tool call. Includes a dashboard for performance stats and run details, plus automated logging to capture inputs, outputs, and execution history.
Navigate to your APIs from the sidebar. Find **Agent History** and click the copy button as shown below.
Click on the **Agent History** API group to enter it.
Click on the \*\*/dashboard \*\*API.
Click on the first step inside of that function stack, and replace the value with the base URL you copied in the previous step.
Navigate to your Database from the sidebar.
Click on the **Agents** table.
Add a new record with the details of the agent you'd like to monitor using the dashboard.
We use a separate table for authentication of the agent monitoring dashboard.
Navigate back to your Database, and click on the **agent\_user** table.
Add a record. This is what you will use to access the Agent dashboard.
In any function stack where you're calling your agent using the **Call Agent** function, add the new **log\_agent** custom function to capture the agent's response and other run information.
From the /dashboard API, copy the endpoint URL using the button at the top of the page.
Paste that URL into a new tab.
Log in using the credentials you stored in the **agent\_user** table.
## Conversation History
Install this snippet to manage and persist user interactions. It's the perfect starting point for any chatbot or conversational agent.
This snippet includes:
* Authentication endpoints (auth/login and auth/me)
* Database tables (conversations and messages, agent\_user)
* Chatbot API group
* A chatbot UI that you can use to test your agents.\\
**Prerequisites**
* Agent must be configured with prompt type set to "Messages"
* Agent messages value must be set to: `{{ $args.messages|json_encode() }}`
Install this snippet to manage and persist user interactions. It's the perfect starting point for any chatbot or conversational agent.
Navigate to your APIs from the sidebar. Find *Chatbot*\* and click the copy button as shown below.
Click on the **Agent History** API group to enter it.
Click on the \*\*/dashboard \*\*API.
Click on the first step inside of that function stack, and replace the value with the base URL you copied in the previous step.
Navigate to your APIs from the sidebar.
Click on the **Conversation** API group, and then select the /conversation API.
In the group called "Add your Agent statement here", add a Call Agent function, and select your agent from the list
In step 5, update the **agent\_response** variable to use the Call AI Agent function's output.
From the /chatbot API, copy the endpoint URL using the button at the top of the page.
Paste that URL into a new tab.
# Agents
Source: https://docs.xano.com/ai-tools/ai-agents
Agents are used to perform 'fuzzy logic', or perform workflows that require intricate decision making, powered by an AI model of your choice
**Not looking for Agents, and just want to connect to your favorite AI models, like ChatGPT?**
**Check out this resource instead:** [Chatbots](/building-backend-features/chatbots)
**Quick Summary**
AI agents in Xano refer to autonomous entities designed to perform tasks by leveraging artificial intelligence. Your Xano Agents can integrate with your database, APIs, tasks, and functions, as well as external systems.
These agents can process data, make decisions, and execute actions without human intervention. AI agents in Xano can efficiently handle a variety of applications, from chatbots to data analysis tools, enhancing automation and productivity.
**Introduction to AI Agents**
**Tools for Agents & MCP Servers**
## What are Agents?
AI agents in Xano serve as integral components for building intelligent, automated systems as a part of your backend. These agents are designed to function autonomously, interacting with various elements of your app such as your APIs and database, as well as external systems, to streamline operations and enhance efficiency. AI agents can intelligently interpret inputs, process data, and deliver actionable outputs, all without the need for continuous human oversight.
Agents in Xano can leverage any of the most popular AI models once you provide an API key, such as:
* OpenAI
* Grok
* Anthropic / Claude
* Google Gemini
You can leverage the same visual builder you're used to using today to create workflows and functions that enable the agents to interact seamlessly with databases and external systems. With these foundational elements in place, AI agents can execute complex tasks, perform data analysis, or even serve as intelligent chatbots, making them versatile tools for a wide range of applications.
## Building Agents in Xano
Please note that **not all models support certain features** such as:
* Structured outputs
* Reasoning
* Tool calls
In addition, some models may support individual features, but not **combinations of features**, such as:
* Structured outputs with tool calls
* Tool calls with reasoning
This is not an issue with Xano or with your agent builds — this is dictated by the model you're using. If you encounter errors when testing your Agents, try using a different model and check to make sure that your model supports the feature(s) you have enabled, especially if you are using more than one of these features together.
## All Agents
Give your agent a name that describes its role or primary function.
**Example:** `Order Processing Agent`
Internal-only field describing what your agent does.
**Example:** Analyzes incoming orders, decides on fulfillment priority, and triggers shipping workflows.
Define dynamic inputs the Agent can accept from Function Stack workflows and reference environment variables.
Use `{{ $args.propertyName }}` for workflow inputs and `{{ $env.variableName }}` for environment variables.
Select the AI model host for the agent.
**Options**
* Anthropic (Claude)
* OpenAI
* Google Gemini
Xano offers limited free Gemini credits for development.
Choose *Xano Test Model (Free Gemini Credits)* to use them.
Credits do not reset once used.
Define how many steps the Agent can execute to complete its task.
**Example:** `5`
Core instructions that define your Agent's role, capabilities, and behavior.
**Example**
> You are a helpful AI Agent that completes tasks accurately.
> When you need additional information to complete a task, use the available tools. Never make assumptions.
The type of prompt provided to the Agent.\
Either `messages` (a list of prior conversation messages) or `prompt` (a single standard prompt).
**Example:** `messages` or `prompt`
Additional context and instructions sent with each request.
**Example**
Please help the customer with their inquiry: `{{ $args.customer_message }}`.
Their account ID is `{{ $args.account_id }}`.
Configure the Agent to return responses in a specific JSON format using your predefined schema.
Toggle the checkbox to enable or disable.
Define the JSON structure for structured outputs.
**Example keys**
* `text`
* `user_email`
Categories for organizing your Agents.
**Example tags**
* `contact`
* `messaging`
Controls logging of requests to [Request History](/maintenance-monitoring-and-logging/request-history).
**Modes**
* **Inherit Settings:** Uses the currently defined workspace settings
* **Disabled:** No logs recorded
* **Enabled:** Logs requests with options for storage limits
## Anthropic Settings
Your Anthropic API key.\
Get your key here.
**Example:** `sk-ant-apixx-xxxxxxxxx-xxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxx`
The Anthropic model to use.\
List of available models here.
**Examples**
* `claude-opus-4-1-20250805`
* `claude-3-7-sonnet-latest`
Controls randomness of the response.
Higher values (e.g. `0.8`) make output more random;
lower values (e.g. `0.2`) make it more focused.
**Examples:** `0.1`, `0.9`
For reasoning models, when enabled, Claude creates `thinking` content blocks showing internal reasoning before the final response.
**Example:** Defaults to `true`
Enables extended thinking and specifies a thinking budget.\
More info here.
**Example JSON**
```json theme={null}
{
"type": "enabled",
"budget_tokens": 10000
}
```
## Google Generative AI (Gemini) Settings
Your Gemini API key.\
Get your key here.
**Example:** `AIzaSyDaGmWKa4JsXZ-HjGw7ISLn_3namBGewQe`
The Gemini model to use.\
List of available models here.
**Examples**
* `gemini-2.5-pro`
* `gemini-2.5-flash-lite`
Controls randomness of the response (creativity).\
Higher = more random, lower = more deterministic.\
More info here.
**Examples:** `0.1`, `0.9`
Grounding with Google Search connects Gemini to real-time web content and enables verifiable sources.\
Works with all available languages.\
Not all models support search grounding.\
More info here.
**Example:** `on` or `off`
Enables extended thinking and specifies a thinking budget.\
More info here.
**Example JSON**
```json theme={null}
{
"thinkingBudget": 1024
}
```
## OpenAI Settings
Your OpenAI API key.\
Get your key here.
**Example:** `sk-Am1rLw7xUwGxGuBasGsNt3BlbkFjdBgBUgBBK5BuG9y6oWWB`
The OpenAI model to use.\
List of available models here.
**Examples**
* `gpt-4.1-mini`
* `gpt-5`
Controls randomness of the response.
Higher values (e.g. `0.8`) make output more random;
lower values (e.g. `0.2`) make it more focused.
**Examples:** `0.1`, `0.9`
For reasoning models, sets how much effort the model spends thinking during generation.
**Examples:** `low`, `medium`, `high`
An Agent needs tools to function — the tools are essentially single functions that the Agent can perform, such as looking up user data or cancelling a subscription.
### Using Existing Function Stacks as Tools
Xano will not make a copy of your existing function stack; instead, it will use a Run Endpoint function and call that function stack internally. This is ideal, so you only have to maintain one function stack.
Instructions are important to have so the AI models and clients interacting with this tool understand how to use it.
### Creating Tools from Scratch
* **Name**
* Give your tool a recognizable name. This is also the command that will be used to execute your tool.
* **Description**
* This is an internal-only field just for you to describe the purpose of the tool.
* **Allow Connections**
* Enable or diffsable connection to this specific tool
* **Add Tag**
* Tag your tools for easier search across your Xano workspace
* **Authentication**
* Determine if this tool requires an authentication token
* **Tool Instructions**
* These instructions are what your clients will use to understand how to send requests to the tool, and what the expected result will be. Markdown format is recommended.
If you haven't already, make sure you're familiar with [Building with Visual Development](/the-function-stack/building-with-visual-development)
From the Agent or MCP Server, choose + Add Tool and select the tool you just created.
## Structured Outputs
Structured Outputs are used for providing a specific format that you need your agent to return its result as. This is especially useful when you are calling agents from other agents and want to ensure that the output from Agent 1 is clear and easy to understand for Agent 2.
You can add structured outputs to your Agent in the settings by checking the Structured Outputs checkbox, and then clicking **+ Add Output Schema** to build your output schema.
## Example Agents
### 🤖 Customer Support Agent
**Purpose**
This Agent is designed to handle customer inquiries that don't typically need human interaction.
**Tools**
An Agent designed for this purpose might have the following tools available:
* **Get User Information**
* Retrieves user information from the database
* **Update User Information**
* Retrieves existing user information from the database, and updates it per a user's request, such as changing their phone number or address
* **Send Verification Code**
* This tool could be used as a secondary security measure to verify that the request is coming from the user that the data belongs to
* **Change Subscription**
* Based on the user's request, this could be used to stop an upcoming renewal, or cancel a subscription immediately. Because Agents excel at 'fuzzy logic' depending on certain circumstances, this could also be used for things like churn prevention — dynamically offering the user a discount to stay, for example
* **Search Documentation**
* Calls an external API from your chosen documentation platform to search your product documentation in an attempt to solve the user's query without human intervention
* **Create Support Ticket**
* In the case that the Agent does not have the necessary tools to solve the user's concerns, create a support ticket for human intervention
### Agent Configuration
| Parameter Name | Purpose | Example |
| ------------------ | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | Give your agent a name that describes its role or primary function | Customer Support Agent |
| Description | Internal only field for describing what your agent does | Handles customer inquiries that don't typically need human interaction. Can retrieve user information, update accounts, send verification codes, manage subscriptions, search documentation, and escalate to human support when needed. |
| Agent Settings | Define dynamic inputs the Agent can accept from Function Stack workflows and reference environment variables | `{{ $args.customer_message }}`, `{{ $args.user_id }}`, `{{ $args.ticket_priority }}`, `{{ $env.SUPPORT_API_KEY }}` |
| Model Host | Select the AI model host for the agent | Claude Sonnet 4 |
| Max Steps | Define how many AI requests the Agent can execute to complete a task | 8 |
| System Prompt | The core instructions that define your Agent's role, capabilities, and behavior | You are a helpful Customer Support Agent that resolves customer inquiries efficiently. Always verify user identity before making account changes. Use available tools to gather information and resolve issues. If you cannot resolve an issue, create a support ticket for human intervention. Be polite, professional, and solution-oriented. |
| Prompt | Additional context and instructions sent with each request | Customer inquiry: `{{ $args.customer_message }}`. User ID: `{{ $args.user_id }}`. Account status: `{{ $args.account_status }}`. Please help resolve this customer's issue while following security protocols. |
| Structured Outputs | Configure your Agent to return responses in JSON format using structured outputs and your predefined schema | ✅ Enabled |
| Output Schema | Define the JSON structure for agent responses | response\_message, action\_taken, ticket\_created, follow\_up\_required |
| Tags | Categories for organizing your Agents | customer-service, support, automation |
| Request History | Controls logging of tool requests | Enabled: Logs requests with options for storage limits |
### Example Interaction Flowcharts
#### 1. Account Information Request
*"What's my current subscription plan?"*
```mermaid theme={null}
flowchart TD
A[Customer asks about subscription] --> B[Get User Information]
B --> C[Retrieve account details]
C --> D[Format response with plan details]
D --> E[Send subscription info to customer]
style A fill:#e1f5fe
style E fill:#e8f5e8
```
#### 2. Address Change Request
*"I need to update my shipping address"*
```mermaid theme={null}
flowchart TD
A[Customer requests address change] --> B{User identity verified?}
B -->|No| C[Send Verification Code]
C --> D{Code valid?}
D -->|No| E[Create Support Ticket]
D -->|Yes| F[Identity confirmed]
B -->|Yes| F
F --> G[Update User Information]
G --> H[Save new address]
H --> I[Confirm changes to customer]
style A fill:#e1f5fe
style I fill:#e8f5e8
style E fill:#ffebee
```
#### 3. Billing Question
*"Why was I charged twice this month?"*
```mermaid theme={null}
flowchart TD
A[Customer reports billing issue] --> B[Get User Information]
B --> C[Review billing history]
C --> D{Simple explanation?}
D -->|Yes| E[Explain charges to customer]
D -->|No| F[Search Documentation]
F --> G{Found billing policy info?}
G -->|Yes| H[Provide policy explanation]
G -->|No| I[Create Support Ticket]
I --> J[Escalate to billing team]
style A fill:#e1f5fe
style E fill:#e8f5e8
style H fill:#e8f5e8
style J fill:#ffebee
```
#### 4. Technical Issue
*"The app keeps crashing on my phone"*
```mermaid theme={null}
flowchart TD
A[Customer reports app crash] --> B[Search Documentation]
B --> C{Found troubleshooting steps?}
C -->|Yes| D[Provide step-by-step guide]
D --> E[Ask if issue resolved]
E -->|Yes| F[Mark as resolved]
E -->|No| G[Create Support Ticket]
C -->|No| G
G --> H[Escalate to technical team]
style A fill:#e1f5fe
style F fill:#e8f5e8
style H fill:#ffebee
```
# MCP Builder
Source: https://docs.xano.com/ai-tools/mcp-builder
#### **Not looking for MCP, and just want to build chatbots or connect to your favorite AI models, like ChatGPT?**
**Check out this resource instead:** [Chatbots](/building-backend-features/chatbots)
**Quick Summary**
**MCP** stands for Model Context Protocol, and is essentially a standardized way for AI models (also referred to as Large Language Models, or LLMs) to interact with other services.
Think about the typical flow every time you interact with an AI. You, the **user**, utilize a **client**, like ChatGPT, to send instructions or ask questions to an **LLM**. The client is responsible for taking your input and transforming it into a way that the LLM you're interacting with can understand.
With MCP in the mix, clients are able to take your input, and instruct an LLM on how to interact with *other* services and tools, like your Xano database, for example. Each separate task that is exposed to the client via the MCP standard is called a **tool**.
Xano's **MCP Builder** feature allows you to build tools just like you build any other function stack and expose them to any client that supports the MCP standard, opening up the opportunity to build for AI, using the power of visual development in Xano.
**Introduction to MCP**
**Build an MCP Server in 10min or Less**
**MCP Tools and Functions**
**Building an MCP Server & Client**
## Introduction to building MCP Servers in Xano
MCP stands for **Model Context Protocol**.
At its core, MCP is a standardized framework that enables seamless communication and interaction between AI models (especially Large Language Models, or LLMs) and external services. Think of it as a universal language and set of rules that allows AI models to go beyond their internal knowledge and capabilities by intelligently leveraging external data sources, tools, and functionalities.
Traditionally, interacting with external services from an AI model required complex and often proprietary integrations built into specific clients. MCP simplifies this by providing a consistent and structured way for client applications to describe available tools and instruct AI models on how to use them. This includes defining the tool's purpose, its input parameters, and how the AI model can expect to receive results.
## Why would I build MCP Servers in Xano?
Building MCP Servers in Xano offers a fundamental shift in how you integrate AI capabilities into your applications. Instead of being limited to building traditional REST APIs for standard web or mobile interactions, Xano's MCP Builder empowers you to create **AI-native functionalities**.
You can build function stacks in Xano specifically designed to be used by AI models. This means that you can create tools for your AI to:
* Retrieve specific data from your Xano database based on natural language queries
* Perform complex data manipulations and calculations triggered by AI insights
* Write data back to your Xano database based on AI-driven decisions or user requests interpreted by the AI
* Interact with other external APIs and services through your Xano function stacks, orchestrated by the AI
* Interact with your own APIs and services you've already built in Xano through the AI
## What's supported with Xano's MCP Builder?
We have built our current MCP support using the SSE transport method. Only tools are available at this time.
You can use any available function we have today in your MCP servers.
As MCP is an evolving protocol, we aim to continue to expand the functionality as it develops. If you are utilizing MCP in Xano and have any feedback or questions, please reach out to our support team.
## Getting Started with MCP Builder
### First, create an MCP Server.
To build MCP servers in Xano, we'll first need to create a server that will house some tools.
* **Name** - Give your server a name that clearly indicates its purpose.
* **Description** - This is an internal field just for you to expand on the
purpose of the MCP server.
* **Allow Connections** - Choose whether or not to allow connections to this MCP server
* **Add Tag** - Tag your MCP servers for easier search throughout your Xano workspace.
* **MCP Instructions** - These instructions are what your clients will look at to understand the purpose of the MCP server. Markdown format is recommended for easy readability for your LLMs and clients. These instructions apply to the server as a whole, and are not used for individual tool instructions.
### After you've created a server, add some tools.
#### What is a tool?
Tools are essentially individual actions that your MCP server can perform, such as querying a database, adding new records, or calling an external API. You'll build tools just like you build any other function stack.
#### Tool Types
You'll select your tool type when connecting a tool to your MCP server, after it's been created.
A tool is an action that your MCP server can perform. Each tool has its own set of logic that defines its behavior, such as querying a database, adding new records, or calling an external API.
Resources allow servers to share data that provides context to language models, such as files, database schemas, or application-specific information. Each resource is uniquely identified by a URI.
From your MCP server, click the ⋮ icon next to the tool you want to change the type on, and select Connection Settings. From there, you can change the tool type. For resource tools, make sure to specify a URI, which is what clients will use to reference the resource.
Use the Resource tool type as part of building apps to run right inside of ChatGPT.
### Using Existing Function Stacks as Tools
Xano will not make a copy of your existing function stack; instead, it will use a Run Endpoint function and call that API internally. This is ideal so you only have to maintain one function stack.
Instructions are important to have so the AI models and clients interacting with this tool understand how to use it.
### Creating Tools from Scratch
* **Name**
* Give your tool a recognizable name. This is also the command that will be used to execute your tool.
* **Description**
* This is an internal-only field just for you to describe the purpose of the tool.
* **Allow Connections**
* Enable or disable connection to this specific tool
* **Add Tag**
* Tag your tools for easier search across your Xano workspace
* **Authentication**
* Determine if this tool requires an authentication token
* **Tool Instructions**
* These instructions are what your clients will use to understand how to send requests to the tool, and what the expected result will be. Markdown format is recommended.
If you haven't already, make sure you're familiar with Xano's [visual builder](/the-function-stack/building-with-visual-development).
We also have some specific functions that may be useful to you when building tools that allow you to interact with existing function stacks.
[MCP Functions](/ai-tools/mcp-builder/mcp-functions)
## MCP Authentication
## **Before you continue**
It's important to understand that MCP is an evolving protocol. Authentication methods and best practices are in flux and may change. The best course of action right now for per-user authentication is to build a custom client that can authenticate your users.
Your MCP tools can have authentication enabled. The method of authentication is a bearer token, similar to the secure APIs you're already building in Xano. You'll include a valid token inside of your client's configuration (if you're using a ready-made client such as Claude Desktop or Cursor), and it will send that token along with your requests.
If you are building a publicly available application with its own user base, and need to make sure that your tools work across your set of users and separates data properly, you'll need to serve your own client that can handle dynamic authentication.
Our end-to-end MCP Server tutorial walks you through one example of building your own server and client, both using Xano.
## MCP Variables
When working with data as part of an MCP tool function stack, you have access to two special variables.
#### token
The Token variable contains a token that is passed as part of the connection URL. This token can be used for building custom authentication, or any other purpose that you see fit.
`https://your-xano-instance.xano.io/x2/mcp/67Dx5RNL/``token_here``/sse`
#### params
You can also pass URL parameters as a part of your connection URL, such as `?beta=true`
`https://yourxano.stage.xano.io/x2/mcp/67Dx5RNL/token_here/sse``?beta=true¶m=here`
You can use the URL parameters in your tool function stacks to determine the behavior of the tool(s).
## Hint
Use the token and / or params in combination with [Triggers](/building/logic/triggers/mcp-servers) for building powerful and complex MCP logic.
One common use: validating the URL `token` in an MCP server trigger so that [clients which can't send an `Authorization` header](/ai-tools/mcp-builder/connecting-clients#clients-without-header-support) — such as Claude Desktop and Claude Web — can still connect securely.
## Connecting to your MCP Server
Now that you've built an MCP server and added some tools to it, you can connect with your client of choice. Choose from the list below for a quick getting started guide.
If you're new to MCP servers, we recommend starting with Cursor.
#### [Cursor](/ai-tools/mcp-builder/connecting-clients#cursor)
#### [Claude Code](/ai-tools/mcp-builder/connecting-clients#claude-code)
***
## Best Practices & FAQs
There are some best practices when building tools that we recommend following for the best experience.
1. [**\*\***Use enum inputs wherever possible\*\*\*\*\*\*](/the-database/database-basics/field-types#enum) so the AI model understands what options are available for your inputs.
2. Use **clear naming conventions** and instructions.
3. **Try to find a balance when writing instructions** between being clear and descriptive, but also concise. Reducing the amount of tokens sent to an AI model will reduce token cost, improve speed, and improve responses.
4. **Use error handling with clear error messages**. If an AI model fails to use a tool, clear error messages will allow it to retry the tool successfully.
* **What are the benefits of using MCP?**
* **Standardization:** MCP provides a common way for different applications and LLMs to interact, reducing the need for custom integrations.
* **Interoperability:** MCP enables different LLMs and applications to work together more easily.
* **Flexibility:** MCP allows developers to connect LLMs to a wide range of external resources.
* **Efficiency:** MCP streamlines the process of building AI agents and applications.
* **Is MCP tied to a specific LLM or platform?**
* No, MCP is designed to be an open and vendor-neutral protocol, allowing it to be used with various LLMs and platforms.
* **How does MCP relate to APIs?**
* While APIs provide access to specific functions, MCP provides a standardized way for LLMs to discover and use those functions in a context-aware manner.
* **What is the role of "context" in MCP?**
* Context is crucial in MCP. It provides the LLM with the necessary information about the user's request, the available tools, and the overall environment, enabling the LLM to make more informed decisions.
* **How is security handled in MCP?**
* MCP emphasizes secure communication between clients and servers. Mechanisms like authentication, authorization, and secure data transfer are important considerations in MCP implementations.
* **Can I build multiple MCP servers?**
* Yes, in Xano you can build multiple MCP servers and they can all have their own tools available.
# Connecting Clients
Source: https://docs.xano.com/ai-tools/mcp-builder/connecting-clients
## Before We Begin
Gather the following information, which you'll need regardless of client.
This is just a name you want to give your MCP server. Make sure it is unique to other MCP servers you're using, and is human readable so you can easily keep track of what each server does.
**For the Xano MCP Server**
> Each instance has its own unique connection URL. The URL can be found inside of your Instance Settings panel from the instance selection screen by clicking the icon next to the instance you want to connect to.
> When creating a URL, you'll need to choose the scope of tools the URL provides. Each client will have its own limits on how many tools can be available at once, so make sure to consult your client's documentation for more information.
**For an MCP Server you built in Xano**
> Click the button next to the MCP server you want in the > screen.
SSE as a connection method has entered deprecation as of [release 2.5](/updates) and will be fully sunset in the upcoming release 2.6. Per the official MCP SDK, you should be using streaming exclusively going forward.
**For the Xano MCP Server**
> The Xano MCP Server token can be found in the same place you retrieved your URL. See [Generating an Access Token](/xano-features/metadata-api#generate-an-access-token) for more information.
**For an MCP Server you built in Xano**
> The token for a custom MCP server is generated the same way your other auth tokens are generated, usually as part of your `signup` and `login` API logic.
Most clients authenticate to Xano MCP servers with a Bearer token sent in an `Authorization` header. Clients that can't send a header — like Claude Desktop and Claude Web — can still connect by placing a token in the URL and validating it server-side. See [Clients without header support](#clients-without-header-support) below.
***
***
## Claude Code
In your terminal, run the following command, replacing ``, ``, and `` with your server's details:
```bash theme={null}
claude mcp add --transport http --header "Authorization: Bearer "
```
***
## Cursor
Cursor supports one-click MCP server installation via install links, with your token sent as an `Authorization` header. Use the generator below to create yours.
***
## Windsurf
Head to Windsurf Settings > Cascade and click **MCP Marketplace**.
Click the icon to access your `mcp_config.json` file directly.
Use the generator below to get the correct JSON.
***
## Antigravity
1. Open the MCP store via the "..." dropdown at the top of the editor's agent panel.
2. Click on "Manage MCP Servers"
3. Click on "View raw config"
4. Modify the mcp\_config.json with your custom MCP server configuration.
Use the generator below to get the correct JSON.
***
## VS Code
These instructions may work for other VS Code-based IDEs, but we recommend consulting that client's official documentation for more specific instructions.
**Per-project**: Create or open `.vscode/mcp.json` in your workspace and add the configuration generated below.
**Across multiple projects**:
1. Run the **MCP: Open User Configuration** command, which opens the `mcp.json` file for your user profile. Add the configuration generated below.
***
## Raycast
Raycast connects to remote MCP servers through its built-in **Install MCP Server** form, which supports custom HTTP headers. Native MCP support requires Raycast 1.98 or later.
1. Run the **Install MCP Server** command, or run **Manage MCP Servers** and choose **Install New Server**.
2. Set **Transport** to **HTTP** and enter your MCP server's **URL**.
3. Under **HTTP Headers**, add a header with the key `Authorization` and the value `Bearer `. Leave the OAuth fields empty — Xano MCP servers authenticate with a static bearer token, not OAuth.
4. Press **⌘ + Enter** to install. Raycast connects to the server and loads its tools, which you can then @-mention in AI Chat.
***
## Warp
1. Access **Warp Drive** and click **MCP Servers** in your Personal settings.
2. Click **+ Add** and add the configuration generated below.
***
## Clients without header support
Some MCP clients — including **Claude Desktop** and **Claude Web** — can only authenticate by putting credentials in the connection URL. Their **Add custom connector** flow accepts a URL but has no field for an `Authorization` header, so Xano's native, header-based MCP authentication won't work for them.
You can still connect these clients securely: put a token **in the URL** and validate it yourself with an MCP server trigger.
Retrieve the streaming connection URL for your MCP server (see [Before We Begin](#before-we-begin)). It looks like this, with `mcp` appearing twice:
`https://your-instance.xano.io/x2/mcp/{server-id}/mcp/streaming`
Replace the **second** `mcp` with your token:
`https://your-instance.xano.io/x2/mcp/{server-id}/{token}/streaming`
This is the value you paste into the client's **Add custom connector** URL field. Server-side, the token is exposed as the [`token` variable](/ai-tools/mcp-builder#mcp-variables).
Native MCP authentication expects an `Authorization` header, which these clients can't send. Leave **Authentication** turned **off** on the tools — you can enforce access with middleware or a trigger instead, so an unauthenticated client can't reach your tools without a valid URL token.
Add an [MCP server trigger](/building/logic/triggers/mcp-servers) that runs on connection and rejects anyone whose URL token isn't valid. The token arrives on the trigger's special `toolset` object as `toolset.token`. If the trigger throws an `accessdenied` error, the connection is refused and no tools run.
On a valid token, the trigger must return the `toolset` and `tools` objects — that's what hands the available tools back to the client — so pass them through unchanged once the check passes.
You can also use middleware for more precise control over the user experience, but triggers are a better option if you have a mix of tools that do and do not require auth.
Please note that if a tool is not using native authentication, it will appear in the list of tools when connected to the MCP server (unless modified via a trigger). We recommend if at all possible, use headers instead.
### Validate a single rotating token
The simplest setup checks the URL token against one environment variable. It's easy to rotate and is shared by everyone who has the URL — a good fit for a system-wide secret.
```xs theme={null}
mcp_server_trigger "validate_url_token" {
mcp_server = "demo"
actions = {connection: true}
active = true
description = "Reject MCP connections that don't carry a valid token in the URL"
// Predefined MCP server trigger input — `toolset.token` is the URL token
input {
object toolset {
schema {
int id
text name
text instructions
text token
}
}
object[] tools {
schema {
int id
text name
text instructions
}
}
}
stack {
var $token { value = $input.toolset.token }
precondition ($token == $env.MCP_URL_TOKEN) {
error_type = "accessdenied"
error = "Invalid or missing MCP token"
}
}
response = { toolset: $input.toolset, tools: $input.tools }
history = false
}
```
### Validate per-user tokens
To attribute connections to individual users — and revoke them independently — store tokens in a table and look them up on connection.
First, a table that maps each token to a user:
```xs theme={null}
table "mcp_token" {
auth = false
schema {
int id
text token { description = "The token value embedded in the MCP connection URL" }
int user_id { description = "Maps this token to a user in your own user table" }
text label? { description = "Human-readable note, e.g. who this token belongs to" }
bool active?=true
timestamp created_at?=now
}
index = [
{type: "primary", field: [{name: "id"}]}
{type: "btree|unique", field: [{name: "token"}]}
]
}
```
Then a trigger that looks the URL token up and rejects anything that isn't an active row:
```xs theme={null}
mcp_server_trigger "validate_url_token" {
mcp_server = "demo"
actions = {connection: true}
active = true
description = "Reject MCP connections whose URL token isn't in the mcp_token table"
input {
object toolset {
schema {
int id
text name
text instructions
text token
}
}
object[] tools {
schema {
int id
text name
text instructions
}
}
}
stack {
var $token { value = $input.toolset.token }
db.get "mcp_token" {
field_name = "token"
field_value = $token
} as $match
precondition ($match != null && $match.active == true) {
error_type = "accessdenied"
error = "Invalid or missing MCP token"
}
}
response = { toolset: $input.toolset, tools: $input.tools }
history = false
}
```
# MCP Functions
Source: https://docs.xano.com/ai-tools/mcp-builder/mcp-functions
## Run API Endpoint
Executes an API endpoint as part of an MCP Server Tool function stack
| Parameter | Purpose |
| --------- | ----------------------------------------------------- |
| API Group | The API group that contains the API you'd like to run |
| Endpoint | The API endpoint to run |
| Return as | The variable to store the output of the API call |
## Note
When using the Run API Endpoint function, authentication tokens are not checked.
## Run Task
Executes a task as part of an MCP Server Tool function stack
| Parameter | Purpose |
| --------- | --------------- |
| Task | The task to run |
Tasks have no output.
## MCP List Tools
Provides a list of available tools and their configurations from an MCP server
| Parameter | Purpose |
| ------------ | --------------------------------------------------------- |
| url | The URL to access the MCP server |
| bearer token | If required, an authentication token to access the server |
## MCP Call Tool
Executes a tool available on a remote MCP server
| Parameter | Purpose |
| ------------ | ------------------------------------------------------------------------------ |
| url | The URL to access the MCP server |
| bearer token | If required, an authentication token to access the server |
| tool name | The name of the tool to call |
| args | The data that the tool requires, if any. This should usually be a JSON object. |
# Xano MCP Server
Source: https://docs.xano.com/ai-tools/xano-mcp-server
Manage your Xano data using your favorite MCP client
## Connect your client
View the [instructions on connecting clients](/ai-tools/mcp-builder/connecting-clients)
## Available Tools
### User Authentication
* **getLoggedInUser** - Validates the provided Access Token and returns the associated account details.
### Workspace Management
* **listWorkspaces** - Lists all workspaces accessible by the authenticated user.
* **getWorkspace** - Retrieves detailed information about a specific workspace.
* **getWorkspaceBranches** - Lists all branches (e.g., development, production) within the specified workspace.
* **workspaceGetDataSources** - Lists all external data sources connected to the specified workspace.
* **workspaceRealtimeDetails** - Retrieves [Realtime](/realtime/realtime-in-xano) information for the specified workspace.
### Table Management
* **addTable** - Creates a new table within the specified workspace.
* **getTables** - Lists all tables within a specific workspace.
* **getTable** - Retrieves the details of a specific table within the workspace.
* **deleteTable** - Deletes a specific table and all data it contains from the workspace.
* **updateTableMeta** - Modifies the metadata (e.g., schema, field definitions, descriptions) of the specified table.
* **updateTableSecurity** - Updates the security rules for the specified table.
### Table Content Management
* **getTableContent** - Retrieves a list of records from the specified table.
* **getTableContentItem** - Retrieves a single, specific record from the table using its ID.
* **updateTableContentItem** - Updates an existing record in the table using its ID.
* **deleteTableContentItem** - Deletes a single, specific record from the table using its ID.
* **searchTableContent** - Searches for records within the table using complex filter criteria and sorting options.
* **patchTableContentBySearch** - Updates fields of all records in the table that match the specified search criteria.
* **deleteTableContentBySearch** - Deletes all records from the table that match the specified search criteria.
* **addTableContentBulk** - Adds multiple new records to the table in a single operation.
* **patchTableContentBulk** - Updates multiple existing records in the table in a single bulk operation.
* **deleteTableContentBulk** - Deletes multiple records from the table in bulk, based on a list of record IDs.
### API Management
* **listAPIGroups** - Lists all API groups within the specified workspace.
* **getApiGroup** - Retrieves details for a specific API group within the workspace.
* **listAPIs** - Lists all individual API endpoints defined within a specific API group.
* **getApiGroupSwagger** - Returns the JSON version of the [Swagger (OpenAPI Documentation)](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation) for a specific API group
* **getApiSwagger** - Returns the JSON version of the [Swagger (OpenAPI Documentation)](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation) for a specific API
### Request Management
* **getRequestHistory** - Lists the history of API requests made to the specified workspace.
* **searchRequestHistory** - Performs an advanced search of the workspace's API request history using filters and sorting.
# Add a workspace addon
Source: https://docs.xano.com/api-reference/addon/add-a-workspace-addon
/apispec_meta_instance.json post /workspace/{workspace_id}/addon
add workspace addons
Authentication: required
# Retrieve a workspace addon
Source: https://docs.xano.com/api-reference/addon/retrieve-a-workspace-addon
/apispec_meta_instance.json get /workspace/{workspace_id}/addon/{addon_id}
get workspace addon
Authentication: required
# Retrieve all workspace addons
Source: https://docs.xano.com/api-reference/addon/retrieve-all-workspace-addons
/apispec_meta_instance.json get /workspace/{workspace_id}/addon
browse workspace addons
Authentication: required
# Update a workspace addon
Source: https://docs.xano.com/api-reference/addon/update-a-workspace-addon
/apispec_meta_instance.json put /workspace/{workspace_id}/addon/{addon_id}
update workspace addons
Authentication: required
# Create a new agent trigger using XanoScript
Source: https://docs.xano.com/api-reference/agent-trigger/create-a-new-agent-trigger-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/agent/trigger
Create a new agent trigger using XanoScript
Authentication: required
# Delete an agent trigger permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/agent-trigger/delete-an-agent-trigger-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/agent/trigger/{trigger_id}
Delete a agent trigger permanently. This action cannot be undone
Authentication: required
# Retrieve all agent triggers
Source: https://docs.xano.com/api-reference/agent-trigger/retrieve-all-agent-triggers
/apispec_meta_instance.json get /workspace/{workspace_id}/agent/trigger
Retrieve all agent triggers
Authentication: required
# Retrieve an agent trigger by ID
Source: https://docs.xano.com/api-reference/agent-trigger/retrieve-an-agent-trigger-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/agent/trigger/{trigger_id}
Retrieve an agent trigger by ID
Authentication: required
# Update agent trigger using XanoScript
Source: https://docs.xano.com/api-reference/agent-trigger/update-agent-trigger-using-xanoscript
/apispec_meta_instance.json put /workspace/{workspace_id}/agent/trigger/{trigger_id}
Update agent trigger using XanoScript
Authentication: required
# Create a new agent using XanoScript
Source: https://docs.xano.com/api-reference/agent/create-a-new-agent-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/agent
Create a new agent using XanoScript
Authentication: required
# Delete an agent permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/agent/delete-an-agent-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/agent/{agent_id}
Delete a agent permanently. This action cannot be undone
Authentication: required
# Retrieve a specific agent by ID
Source: https://docs.xano.com/api-reference/agent/retrieve-a-specific-agent-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/agent/{agent_id}
Retrieve a specific agent by ID
Authentication: required
# Retrieve all agents in a workspace
Source: https://docs.xano.com/api-reference/agent/retrieve-all-agents-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/agent
Retrieve all agents in a workspace
Authentication: required
# Update agent details using XanoScript
Source: https://docs.xano.com/api-reference/agent/update-agent-details-using-xanoscript
/apispec_meta_instance.json put /workspace/{workspace_id}/agent/{agent_id}
Update agent details using XanoScript
Authentication: required
# Create a new API endpoint using XanoScript
Source: https://docs.xano.com/api-reference/api-group-api/create-a-new-api-endpoint-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/apigroup/{apigroup_id}/api
Create a new API endpoint using XanoScript
Authentication: required
# Delete an API endpoint permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/api-group-api/delete-an-api-endpoint-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/apigroup/{apigroup_id}/api/{api_id}
Delete an API endpoint permanently. This action cannot be undone
Authentication: required
# Generate OpenAPI specification for a specific API endpoint
Source: https://docs.xano.com/api-reference/api-group-api/generate-openapi-specification-for-a-specific-api-endpoint
/apispec_meta_instance.json get /workspace/{workspace_id}/apigroup/{apigroup_id}/api/{api_id}/openapi
Generate OpenAPI specification for a specific API endpoint
Authentication: required
Required API Scope:
Workspace Api: Read
# Retrieve a specific API endpoint by ID
Source: https://docs.xano.com/api-reference/api-group-api/retrieve-a-specific-api-endpoint-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/apigroup/{apigroup_id}/api/{api_id}
Retrieve a specific API endpoint by ID
Authentication: required
# Retrieve all API endpoints in a group
Source: https://docs.xano.com/api-reference/api-group-api/retrieve-all-api-endpoints-in-a-group
/apispec_meta_instance.json get /workspace/{workspace_id}/apigroup/{apigroup_id}/api
Retrieve all API endpoints in a group
Authentication: required
# Update an API endpoint
Source: https://docs.xano.com/api-reference/api-group-api/update-an-api-endpoint
/apispec_meta_instance.json put /workspace/{workspace_id}/apigroup/{apigroup_id}/api/{api_id}
Update API endpoint code, settings, and authentication rules
Authentication: required
# Update API endpoint security settings
Source: https://docs.xano.com/api-reference/api-group-api/update-api-endpoint-security-settings
/apispec_meta_instance.json put /workspace/{workspace_id}/apigroup/{apigroup_id}/api/{api_id}/security
Update API endpoint security configuration and access controls
Authentication: required
# Create a new API group
Source: https://docs.xano.com/api-reference/api-group/create-a-new-api-group
/apispec_meta_instance.json post /workspace/{workspace_id}/apigroup
Create a new API group in a workspace. Include name, description, and optional tags.
Authentication: required
# Delete an API group
Source: https://docs.xano.com/api-reference/api-group/delete-an-api-group
/apispec_meta_instance.json delete /workspace/{workspace_id}/apigroup/{apigroup_id}
Delete an API group and all its endpoints. This action cannot be undone.
Authentication: required
# Get OpenAPI spec for an API group
Source: https://docs.xano.com/api-reference/api-group/get-openapi-spec-for-an-api-group
/apispec_meta_instance.json get /workspace/{workspace_id}/apigroup/{apigroup_id}/openapi
Get the OpenAPI specification for an API group. Returns the complete Swagger JSON for all endpoints.
Authentication: required
Required API Scope:
Workspace Api: Read
# Retrieve a specific API group
Source: https://docs.xano.com/api-reference/api-group/retrieve-a-specific-api-group
/apispec_meta_instance.json get /workspace/{workspace_id}/apigroup/{apigroup_id}
Get detailed information for a specific API group. Returns complete metadata and configuration.
Authentication: required
# Retrieve all API groups in a workspace
Source: https://docs.xano.com/api-reference/api-group/retrieve-all-api-groups-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/apigroup
Retrieve a list of API groups inside of a workspace. Use the optional filtering and sorting parameters for more granular returns.
Authentication: required
# Update an API group
Source: https://docs.xano.com/api-reference/api-group/update-an-api-group
/apispec_meta_instance.json put /workspace/{workspace_id}/apigroup/{apigroup_id}
Update an existing API group. Modify name, description, documentation settings, or tags.
Authentication: required
# Update API group security settings
Source: https://docs.xano.com/api-reference/api-group/update-api-group-security-settings
/apispec_meta_instance.json put /workspace/{workspace_id}/apigroup/{apigroup_id}/security
Update security settings for an API group. Configure access permissions and authentication requirements.
Authentication: required
# Browse audit logs across all workspaces
Source: https://docs.xano.com/api-reference/audit-logs/browse-audit-logs-across-all-workspaces
/apispec_meta_instance.json get /audit_log
browse audit logs across all workspaces
Authentication: required
# Retrieve workspace audit logs with pagination support
Source: https://docs.xano.com/api-reference/audit-logs/retrieve-workspace-audit-logs-with-pagination-support
/apispec_meta_instance.json get /workspace/{workspace_id}/audit_log
Retrieve workspace audit logs with pagination support
Authentication: required
Required API Scope:
Workspace Log: Read
# Search audit logs across all workspaces
Source: https://docs.xano.com/api-reference/audit-logs/search-audit-logs-across-all-workspaces
/apispec_meta_instance.json post /audit_log/search
search audit logs across all workspaces with support for complex filtering and sorting
Authentication: required
# Search workspace audit logs
Source: https://docs.xano.com/api-reference/audit-logs/search-workspace-audit-logs
/apispec_meta_instance.json post /workspace/{workspace_id}/audit_log/search
Search audit logs using advanced filters and custom sorting options
Authentication: required
Required API Scope:
Workspace Log: Read
# Retrieve information about the authenticated user including ID, name, and email address.
Source: https://docs.xano.com/api-reference/authentication/retrieve-information-about-the-authenticated-user-including-id-name-and-email-address
/apispec_meta_instance.json get /auth/me
Retrieve information about the authenticated user including ID, name, and email address.
Authentication: required
# Create a new branch by cloning an existing branch.
Source: https://docs.xano.com/api-reference/branch/create-a-new-branch-by-cloning-an-existing-branch
/apispec_meta_instance.json post /workspace/{workspace_id}/branch
Create a new branch by cloning an existing branch.
Authentication: required
Required API Scope:
Instance Workspace: Update
# Delete a workspace branch
Source: https://docs.xano.com/api-reference/branch/delete-a-workspace-branch
/apispec_meta_instance.json delete /workspace/{workspace_id}/branch/{branch_label}
Delete a workspace branch. Cannot delete the default branch or currently live branch.
Authentication: required
Required API Scope:
Instance Workspace: Update
# Retrieve a specific branch by label.
Source: https://docs.xano.com/api-reference/branch/retrieve-a-specific-branch-by-label
/apispec_meta_instance.json get /workspace/{workspace_id}/branch/{branch_label}
Retrieve a specific branch by label.
Authentication: required
Required API Scope:
Instance Workspace: Read
# Retrieve all branches in a workspace.
Source: https://docs.xano.com/api-reference/branch/retrieve-all-branches-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/branch
Retrieve all branches in a workspace.
Authentication: required
Required API Scope:
Instance Workspace: Read
# Set a branch as the live (active) branch for the workspace.
Source: https://docs.xano.com/api-reference/branch/set-a-branch-as-the-live-active-branch-for-the-workspace
/apispec_meta_instance.json post /workspace/{workspace_id}/branch/{branch_label}/live
Set a branch as the live (active) branch for the workspace.
Authentication: required
Required API Scope:
Instance Workspace: Update
# Update a workspace branch
Source: https://docs.xano.com/api-reference/branch/update-a-workspace-branch
/apispec_meta_instance.json put /workspace/{workspace_id}/branch/{branch_label}
Update an existing branch's label, description, or color.
Authentication: required
Required API Scope:
Instance Workspace: Update
# Convert from JSON to XanoScript
Source: https://docs.xano.com/api-reference/convert/convert-from-json-to-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/convert/toXS
Authentication: required
Required API Scope:
Instance Workspace: Read
# Convert from XanoScript to JSON
Source: https://docs.xano.com/api-reference/convert/convert-from-xanoscript-to-json
/apispec_meta_instance.json post /workspace/{workspace_id}/convert/fromXS
Authentication: required
Required API Scope:
Instance Workspace: Read
# Delete a file permanently. This action cannot be undone.
Source: https://docs.xano.com/api-reference/file/delete-a-file-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/file/{file_id}
Delete a file permanently. This action cannot be undone.
Authentication: required
Required API Scope:
Workspace File: Delete
# Delete multiple files permanently. This action cannot be undone.
Source: https://docs.xano.com/api-reference/file/delete-multiple-files-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/file/bulk_delete
Delete multiple files permanently. This action cannot be undone.
Authentication: required
Required API Scope:
Workspace File: Delete
# Retrieve workspace files
Source: https://docs.xano.com/api-reference/file/retrieve-workspace-files
/apispec_meta_instance.json get /workspace/{workspace_id}/file
Retrieve workspace files with optional search, filtering, and pagination
Authentication: required
Required API Scope:
Workspace File: Read
# Upload files to workspace
Source: https://docs.xano.com/api-reference/file/upload-files-to-workspace
/apispec_meta_instance.json post /workspace/{workspace_id}/file
Upload files to workspace
Authentication: required
Required API Scope:
Workspace File: Create
# Create a new function using XanoScript
Source: https://docs.xano.com/api-reference/function/create-a-new-function-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/function
Create a new function using XanoScript
Authentication: required
# Delete a function permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/function/delete-a-function-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/function/{function_id}
Delete a function permanently. This action cannot be undone
Authentication: required
# Retrieve a specific function by ID
Source: https://docs.xano.com/api-reference/function/retrieve-a-specific-function-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/function/{function_id}
Retrieve a specific function by ID
Authentication: required
# Retrieve all functions in a workspace
Source: https://docs.xano.com/api-reference/function/retrieve-all-functions-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/function
Retrieve all functions in a workspace
Authentication: required
# Update a function
Source: https://docs.xano.com/api-reference/function/update-a-function
/apispec_meta_instance.json put /workspace/{workspace_id}/function/{function_id}
Update function code, metadata, and caching settings
Authentication: required
# Update function security settings
Source: https://docs.xano.com/api-reference/function/update-function-security-settings
/apispec_meta_instance.json put /workspace/{workspace_id}/function/{function_id}/security
Update function security configuration and access controls
Authentication: required
# Create a new MCP server trigger using XanoScript
Source: https://docs.xano.com/api-reference/mcp-server-trigger/create-a-new-mcp-server-trigger-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/mcp_server/trigger
Create a new mcp_server trigger using XanoScript
Authentication: required
# Delete an MCP server trigger permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/mcp-server-trigger/delete-an-mcp-server-trigger-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/mcp_server/trigger/{trigger_id}
Delete a mcp_server trigger permanently. This action cannot be undone
Authentication: required
# Retrieve all MCP server triggers
Source: https://docs.xano.com/api-reference/mcp-server-trigger/retrieve-all-mcp-server-triggers
/apispec_meta_instance.json get /workspace/{workspace_id}/mcp_server/trigger
Retrieve all mcp_server triggers
Authentication: required
# Retrieve an MCP server trigger by ID
Source: https://docs.xano.com/api-reference/mcp-server-trigger/retrieve-an-mcp-server-trigger-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/mcp_server/trigger/{trigger_id}
Retrieve an mcp_server trigger by ID
Authentication: required
# Update an MCP server trigger using XanoScript
Source: https://docs.xano.com/api-reference/mcp-server-trigger/update-an-mcp-server-trigger-using-xanoscript
/apispec_meta_instance.json put /workspace/{workspace_id}/mcp_server/trigger/{trigger_id}
Update mcp_server trigger using XanoScript
Authentication: required
# Update MCP server trigger security settings
Source: https://docs.xano.com/api-reference/mcp-server-trigger/update-mcp-server-trigger-security-settings
/apispec_meta_instance.json put /workspace/{workspace_id}/mcp_server/trigger/{trigger_id}/security
Update mcp_server trigger security configuration and access controls
Authentication: required
# Create a new MCP server using XanoScript
Source: https://docs.xano.com/api-reference/mcp-server/create-a-new-mcp-server-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/mcp_server
Create a new MCP server using XanoScript
Authentication: required
# Delete a MCP server permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/mcp-server/delete-a-mcp-server-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/mcp_server/{mcp_server_id}
Delete a MCP server permanently. This action cannot be undone
Authentication: required
# Retrieve a specific MCP server by ID
Source: https://docs.xano.com/api-reference/mcp-server/retrieve-a-specific-mcp-server-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/mcp_server/{mcp_server_id}
Retrieve a specific MCP server by ID
Authentication: required
# Retrieve all MCP servers in a workspace
Source: https://docs.xano.com/api-reference/mcp-server/retrieve-all-mcp-servers-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/mcp_server
Retrieve all MCP servers in a workspace
Authentication: required
# Retrieve MCP server documentation and available commands
Source: https://docs.xano.com/api-reference/mcp-server/retrieve-mcp-server-documentation-and-available-commands
/apispec_meta_instance.json get /mcp_server/documentation
Documentation endpoint that provides a comprehensive overview of the MCP Server's operation and includes detailed documentation for the XanoScript syntax. Use the type "start" to view all available commands.
Authentication: required
# Update MCP server details using XanoScript
Source: https://docs.xano.com/api-reference/mcp-server/update-mcp-server-details-using-xanoscript
/apispec_meta_instance.json put /workspace/{workspace_id}/mcp_server/{mcp_server_id}
Update MCP server details using XanoScript
Authentication: required
# Create a new middleware using XanoScript
Source: https://docs.xano.com/api-reference/middleware/create-a-new-middleware-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/middleware
Create a new middleware using XanoScript
Authentication: required
# Delete a middleware permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/middleware/delete-a-middleware-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/middleware/{middleware_id}
Delete a middleware permanently. This action cannot be undone
Authentication: required
# Retrieve a specific middleware by ID
Source: https://docs.xano.com/api-reference/middleware/retrieve-a-specific-middleware-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/middleware/{middleware_id}
Retrieve a specific middleware by ID
Authentication: required
# Retrieve all middlewares in a workspace
Source: https://docs.xano.com/api-reference/middleware/retrieve-all-middlewares-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/middleware
Retrieve all middlewares in a workspace
Authentication: required
# Update a middleware
Source: https://docs.xano.com/api-reference/middleware/update-a-middleware
/apispec_meta_instance.json put /workspace/{workspace_id}/middleware/{middleware_id}
Update middleware code, metadata, and caching settings
Authentication: required
# Update middleware security settings
Source: https://docs.xano.com/api-reference/middleware/update-middleware-security-settings
/apispec_meta_instance.json put /workspace/{workspace_id}/middleware/{middleware_id}/security
Update middleware security configuration and access controls
Authentication: required
# Create a new realtime trigger using XanoScript
Source: https://docs.xano.com/api-reference/realtime-trigger/create-a-new-realtime-trigger-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/realtime/channel/trigger
Create a new realtime trigger using XanoScript
Authentication: required
# Delete a realtime trigger permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/realtime-trigger/delete-a-realtime-trigger-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/realtime/channel/trigger/{trigger_id}
Delete a realtime trigger permanently. This action cannot be undone
Authentication: required
# Retrieve a realtime trigger by ID
Source: https://docs.xano.com/api-reference/realtime-trigger/retrieve-a-realtime-trigger-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/realtime/channel/trigger/{trigger_id}
Retrieve a realtime trigger by ID
Authentication: required
# Retrieve all realtime triggers
Source: https://docs.xano.com/api-reference/realtime-trigger/retrieve-all-realtime-triggers
/apispec_meta_instance.json get /workspace/{workspace_id}/realtime/channel/trigger
Retrieve all realtime triggers
Authentication: required
# Update realtime trigger using XanoScript
Source: https://docs.xano.com/api-reference/realtime-trigger/update-realtime-trigger-using-xanoscript
/apispec_meta_instance.json put /workspace/{workspace_id}/realtime/channel/trigger/{trigger_id}
Update realtime trigger using XanoScript
Authentication: required
# Create a new realtime channel using XanoScript
Source: https://docs.xano.com/api-reference/realtime/create-a-new-realtime-channel-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/realtime/channel
Create a new realtime channel using XanoScript
Authentication: required
# Delete a realtime channel permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/realtime/delete-a-realtime-channel-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/realtime/channel/{channel_id}
Delete a realtime channel permanently. This action cannot be undone
Authentication: required
# Retrieve a realtime channel
Source: https://docs.xano.com/api-reference/realtime/retrieve-a-realtime-channel
/apispec_meta_instance.json get /workspace/{workspace_id}/realtime/channel/{channel_id}
get realtime channel
Authentication: required
# Retrieve all realtime channels
Source: https://docs.xano.com/api-reference/realtime/retrieve-all-realtime-channels
/apispec_meta_instance.json get /workspace/{workspace_id}/realtime/channel
Retrieve all realtime channels
Authentication: required
# Retrieve real-time operational metrics and connection details
Source: https://docs.xano.com/api-reference/realtime/retrieve-real-time-operational-metrics-and-connection-details
/apispec_meta_instance.json get /workspace/{workspace_id}/realtime
Retrieve real-time operational metrics and connection details
Authentication: required
Required API Scope:
Instance Workspace: Read
# Update real-time settings and connection configuration
Source: https://docs.xano.com/api-reference/realtime/update-real-time-settings-and-connection-configuration
/apispec_meta_instance.json put /workspace/{workspace_id}/realtime
Update real-time settings and connection configuration
Authentication: required
Required API Scope:
Instance Workspace: Update
# Update realtime channel details using XanoScript
Source: https://docs.xano.com/api-reference/realtime/update-realtime-channel-details-using-xanoscript
/apispec_meta_instance.json put /workspace/{workspace_id}/realtime/channel/{channel_id}
Update realtime channel details using XanoScript
Authentication: required
# Retrieve API function request history
Source: https://docs.xano.com/api-reference/request-history/retrieve-api-function-request-history
/apispec_meta_instance.json get /workspace/{workspace_id}/function_history
Retrieve API function request history
Authentication: required
Required API Scope:
Workspace Request History: Read
# Retrieve API request history
Source: https://docs.xano.com/api-reference/request-history/retrieve-api-request-history
/apispec_meta_instance.json get /workspace/{workspace_id}/request_history
Retrieve API request history
Authentication: required
Required API Scope:
Workspace Request History: Read
# Retrieve middleware request history
Source: https://docs.xano.com/api-reference/request-history/retrieve-middleware-request-history
/apispec_meta_instance.json get /workspace/{workspace_id}/middleware_history
Retrieve middleware request history
Authentication: required
Required API Scope:
Workspace Request History: Read
# Retrieve task request history
Source: https://docs.xano.com/api-reference/request-history/retrieve-task-request-history
/apispec_meta_instance.json get /workspace/{workspace_id}/task_history
Retrieve task request history
Authentication: required
Required API Scope:
Workspace Request History: Read
# Retrieve tool request history
Source: https://docs.xano.com/api-reference/request-history/retrieve-tool-request-history
/apispec_meta_instance.json get /workspace/{workspace_id}/tool_history
Retrieve tool request history
Authentication: required
Required API Scope:
Workspace Request History: Read
# Retrieve trigger request history
Source: https://docs.xano.com/api-reference/request-history/retrieve-trigger-request-history
/apispec_meta_instance.json get /workspace/{workspace_id}/trigger_history
Retrieve trigger request history
Authentication: required
Required API Scope:
Workspace Request History: Read
# Search API request history
Source: https://docs.xano.com/api-reference/request-history/search-api-request-history
/apispec_meta_instance.json post /workspace/{workspace_id}/request_history/search
Search API request history using advanced filters and custom sorting options
Authentication: required
Required API Scope:
Workspace Request History: Read
# Search function request history
Source: https://docs.xano.com/api-reference/request-history/search-function-request-history
/apispec_meta_instance.json post /workspace/{workspace_id}/function_history/search
Search function request history using advanced filters and custom sorting options
Authentication: required
Required API Scope:
Workspace Request History: Read
# Search middleware request history
Source: https://docs.xano.com/api-reference/request-history/search-middleware-request-history
/apispec_meta_instance.json post /workspace/{workspace_id}/middleware_history/search
Search middleware request history using advanced filters and custom sorting options
Authentication: required
Required API Scope:
Workspace Request History: Read
# Search task request history
Source: https://docs.xano.com/api-reference/request-history/search-task-request-history
/apispec_meta_instance.json post /workspace/{workspace_id}/task_history/search
Search task request history using advanced filters and custom sorting options
Authentication: required
Required API Scope:
Workspace Request History: Read
# Search tool request history
Source: https://docs.xano.com/api-reference/request-history/search-tool-request-history
/apispec_meta_instance.json post /workspace/{workspace_id}/tool_history/search
Search tool request history using advanced filters and custom sorting options
Authentication: required
Required API Scope:
Workspace Request History: Read
# Search trigger request history
Source: https://docs.xano.com/api-reference/request-history/search-trigger-request-history
/apispec_meta_instance.json post /workspace/{workspace_id}/trigger_history/search
Search trigger request history using advanced filters and custom sorting options
Authentication: required
Required API Scope:
Workspace Request History: Read
# Create a static host build
Source: https://docs.xano.com/api-reference/static-host/create-a-static-host-build
/apispec_meta_instance.json post /workspace/{workspace_id}/static_host/{static_host}/build
create a static host build
Authentication: required
# Delete a static host build
Source: https://docs.xano.com/api-reference/static-host/delete-a-static-host-build
/apispec_meta_instance.json delete /workspace/{workspace_id}/static_host/{static_host}/build/{build_id}
delete a static host build
Authentication: required
# Retrieve a specific build for a static host
Source: https://docs.xano.com/api-reference/static-host/retrieve-a-specific-build-for-a-static-host
/apispec_meta_instance.json get /workspace/{workspace_id}/static_host/{static_host}/build/{build_id}
Retrieve a specific build for a static host
Authentication: required
# Retrieve builds for a static host
Source: https://docs.xano.com/api-reference/static-host/retrieve-builds-for-a-static-host
/apispec_meta_instance.json get /workspace/{workspace_id}/static_host/{static_host}/build
Retrieve builds for a static host
Authentication: required
# Create a new record in the table
Source: https://docs.xano.com/api-reference/table-content/create-a-new-record-in-the-table
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/content
Each table has unique schema, which means that the request body should be updated with the schema relevant to the table being used.
The example below is assuming that the table has a column labeled "name".
Required API Scope:
Workspace Content: Create
# Create multiple records in a single batch operation
Source: https://docs.xano.com/api-reference/table-content/create-multiple-records-in-a-single-batch-operation
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/content/bulk
Each table has unique schema, which means that the request body should be an array of objects with the schema relevant to the table being used.
The example below is assuming that the table has a column labeled "name".
Required API Scope:
Workspace Content: Create
# Delete a specific record by ID
Source: https://docs.xano.com/api-reference/table-content/delete-a-specific-record-by-id
/apispec_meta_instance.json delete /workspace/{workspace_id}/table/{table_id}/content/{content_id}
Delete a specific record by ID
Authentication: required
Required API Scope:
Workspace Content: Delete
# Delete all records matching specified search criteria
Source: https://docs.xano.com/api-reference/table-content/delete-all-records-matching-specified-search-criteria
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/content/search/delete
Provide search criteria to delete all matching rows.
Required API Scope:
Workspace Content: Delete
# Delete multiple records by their IDs in a single operation
Source: https://docs.xano.com/api-reference/table-content/delete-multiple-records-by-their-ids-in-a-single-operation
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/content/bulk/delete
The request body should contain an array of **row_ids**, where each id identifies a row to be deleted.
Required API Scope:
Workspace Content: Delete
# Retrieve a specific record by ID
Source: https://docs.xano.com/api-reference/table-content/retrieve-a-specific-record-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/table/{table_id}/content/{content_id}
Retrieve a specific record by ID
Authentication: required
Required API Scope:
Workspace Content: Read
# Retrieve paginated records from a table
Source: https://docs.xano.com/api-reference/table-content/retrieve-paginated-records-from-a-table
/apispec_meta_instance.json get /workspace/{workspace_id}/table/{table_id}/content
Retrieve paginated records from a table
Authentication: required
Required API Scope:
Workspace Content: Read
# Search table records
Source: https://docs.xano.com/api-reference/table-content/search-table-records
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/content/search
Search table records with advanced filtering and sorting options
Authentication: required
Required API Scope:
Workspace Content: Read
# Truncate a database table
Source: https://docs.xano.com/api-reference/table-content/truncate-a-database-table
/apispec_meta_instance.json delete /workspace/{workspace_id}/table/{table_id}/truncate
Delete all records from the table and optionally reset the primary key
Authentication: required
Required API Scope:
Workspace Content: Delete
# Update a specific record by ID
Source: https://docs.xano.com/api-reference/table-content/update-a-specific-record-by-id
/apispec_meta_instance.json put /workspace/{workspace_id}/table/{table_id}/content/{content_id}
Each table has unique schema, which means that the request body should be updated with the schema relevant to the table being used.
The example below is assuming that the table has a column labeled "name".
Required API Scope:
Workspace Content: Update
# Update all records matching specified search criteria
Source: https://docs.xano.com/api-reference/table-content/update-all-records-matching-specified-search-criteria
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/content/search/patch
Provide search and update objects with path and new value to patch rows matching search criteria.
Required API Scope:
Workspace Content: Update
# Update multiple records in a single batch operation
Source: https://docs.xano.com/api-reference/table-content/update-multiple-records-in-a-single-batch-operation
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/content/bulk/patch
The request body should contain an array of **items**, where each item represents a row to be updated. For each row, provide the **row_id** and **updates** array that specifies the columns (**path**) to update and the new values (**value**).
The example below is assuming that the table being modified has a column labeled *name*.
Required API Scope:
Workspace Content: Update
# Create a btree index on table columns
Source: https://docs.xano.com/api-reference/table-index/create-a-btree-index-on-table-columns
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/index/btree
Create a btree index on table columns to optimize query performance
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a full-text search index on table columns
Source: https://docs.xano.com/api-reference/table-index/create-a-full-text-search-index-on-table-columns
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/index/search
Create a full-text search index for table columns with language-specific optimization
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a spatial index on a table
Source: https://docs.xano.com/api-reference/table-index/create-a-spatial-index-on-a-table
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/index/spatial
Create a spatial index on a table for optimized geometry operations
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a unique index on table columns
Source: https://docs.xano.com/api-reference/table-index/create-a-unique-index-on-table-columns
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/index/unique
Create a unique index on table fields to enforce data uniqueness and improve query performance
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a vector index on a table column
Source: https://docs.xano.com/api-reference/table-index/create-a-vector-index-on-a-table-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/index/vector
Options include `vector_ip_ops` (Inner Product), `vector_cosine_ops` (Cosine), `vector_l1_ops` (L1 Distance), `vector_l2_ops` (L2 Distance)
Required API Scope:
Workspace Database: Create
# Delete a specific table index. This action cannot be undone.
Source: https://docs.xano.com/api-reference/table-index/delete-a-specific-table-index-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/table/{table_id}/index/{index_id}
Delete a specific table index. This action cannot be undone.
Authentication: required
Required API Scope:
Workspace Database: Delete
# Replace all indexes for a database table
Source: https://docs.xano.com/api-reference/table-index/replace-all-indexes-for-a-database-table
/apispec_meta_instance.json put /workspace/{workspace_id}/table/{table_id}/index
Replace all indexes for a database table with new index configuration
Authentication: required
Required API Scope:
Workspace Database: Update
# Retrieve all indexes for a database table
Source: https://docs.xano.com/api-reference/table-index/retrieve-all-indexes-for-a-database-table
/apispec_meta_instance.json get /workspace/{workspace_id}/table/{table_id}/index
Retrieve all indexes for a database table
Authentication: required
Required API Scope:
Workspace Database: Read
# Create a boolean column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-boolean-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/bool
Create a boolean column with true/false values and optional default settings
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a date column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-date-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/date
Create a date column for storing calendar dates without time information
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a decimal column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-decimal-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/decimal
Create a decimal column for precise numeric values with configurable min/max limits
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a geographic linestring column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-geographic-linestring-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/geo_linestring
Create a geographic linestring column for storing connected coordinate paths
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a geographic multilinestring column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-geographic-multilinestring-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/geo_multilinestring
Create a geographic multilinestring column for storing multiple coordinate paths
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a geographic multipoint column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-geographic-multipoint-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/geo_multipoint
Create a geographic multipoint column for storing collections of coordinate points
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a geographic multipolygon column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-geographic-multipolygon-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/geo_multipolygon
Create a geographic multipolygon column for storing complex area boundaries
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a geographic point column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-geographic-point-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/geo_point
Create a geographic point column for storing latitude/longitude coordinates
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a geographic polygon column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-geographic-polygon-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/geo_polygon
Create a geographic polygon column for storing area boundaries and shapes
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a JSON column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-json-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/json
Create a JSON column for storing structured data objects and arrays
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a password column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-password-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/password
Create a password column with automatic hashing and complexity validation rules
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a table reference column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-table-reference-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/tableref
Create a table reference column to establish relationships with other database tables
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a text column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-text-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/text
Create a text column with formatting options and customizable validation rules
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a timestamp column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-timestamp-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/timestamp
Create a timestamp column for storing precise date and time values
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a UUID-based table reference column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-uuid-based-table-reference-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/tablerefuuid
Create a UUID-based table reference column for relationships with UUID primary keys
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a UUID column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-uuid-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/uuid
Create a UUID column for generating universally unique identifiers
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a vector column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-vector-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/vector
Create a vector column for storing multi-dimensional data used in AI and ML applications
Authentication: required
Required API Scope:
Workspace Database: Create
# Create a video column
Source: https://docs.xano.com/api-reference/table-schema-type/create-a-video-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/video
Create a video file column for storing video uploads and media content
Authentication: required
Required API Scope:
Workspace Database: Create
# Create an attachment column
Source: https://docs.xano.com/api-reference/table-schema-type/create-an-attachment-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/attachment
Create an attachment column for file uploads in a database table
Authentication: required
Required API Scope:
Workspace Database: Create
# Create an audio column
Source: https://docs.xano.com/api-reference/table-schema-type/create-an-audio-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/audio
Create an audio file column for storing audio uploads and media
Authentication: required
Required API Scope:
Workspace Database: Create
# Create an email column
Source: https://docs.xano.com/api-reference/table-schema-type/create-an-email-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/email
Create an email column with built-in email format validation
Authentication: required
Required API Scope:
Workspace Database: Create
# Create an enum column
Source: https://docs.xano.com/api-reference/table-schema-type/create-an-enum-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/enum
Create an enum column with predefined value options for dropdown selections
Authentication: required
Required API Scope:
Workspace Database: Create
# Create an image column
Source: https://docs.xano.com/api-reference/table-schema-type/create-an-image-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/image
Create an image column for storing photo uploads and visual media
Authentication: required
Required API Scope:
Workspace Database: Create
# Create an integer column
Source: https://docs.xano.com/api-reference/table-schema-type/create-an-integer-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/int
Create an integer column for whole numbers with configurable min/max limits
Authentication: required
Required API Scope:
Workspace Database: Create
# Create an object column
Source: https://docs.xano.com/api-reference/table-schema-type/create-an-object-column
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/type/object
Create an object column with nested child fields for complex data structures
Authentication: required
Required API Scope:
Workspace Database: Create
# Delete a column from a table's schema. This action cannot be undone.
Source: https://docs.xano.com/api-reference/table-schema/delete-a-column-from-a-tables-schema-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/table/{table_id}/schema/{schema_name}
Delete a column from a table's schema. This action cannot be undone.
Authentication: required
Required API Scope:
Workspace Database: Delete
# Rename a column in a table's schema
Source: https://docs.xano.com/api-reference/table-schema/rename-a-column-in-a-tables-schema
/apispec_meta_instance.json post /workspace/{workspace_id}/table/{table_id}/schema/rename
Rename a column in a table's schema
Authentication: required
Required API Scope:
Workspace Database: Update
# Replace the entire schema definition for a database table
Source: https://docs.xano.com/api-reference/table-schema/replace-the-entire-schema-definition-for-a-database-table
/apispec_meta_instance.json put /workspace/{workspace_id}/table/{table_id}/schema
Replace the entire schema definition for a database table
Authentication: required
Required API Scope:
Workspace Database: Update
# Retrieve details for a specific column in a table's schema
Source: https://docs.xano.com/api-reference/table-schema/retrieve-details-for-a-specific-column-in-a-tables-schema
/apispec_meta_instance.json get /workspace/{workspace_id}/table/{table_id}/schema/{schema_name}
Retrieve details for a specific column in a table's schema
Authentication: required
Required API Scope:
Workspace Database: Read
# Retrieve the complete schema definition for a database table
Source: https://docs.xano.com/api-reference/table-schema/retrieve-the-complete-schema-definition-for-a-database-table
/apispec_meta_instance.json get /workspace/{workspace_id}/table/{table_id}/schema
Retrieve the complete schema definition for a database table
Authentication: required
Required API Scope:
Workspace Database: Read
# Create a new table trigger using XanoScript
Source: https://docs.xano.com/api-reference/table-trigger/create-a-new-table-trigger-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/table/trigger
Create a new table trigger using XanoScript
Authentication: required
# Delete a table trigger permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/table-trigger/delete-a-table-trigger-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/table/trigger/{trigger_id}
Delete a table trigger permanently. This action cannot be undone
Authentication: required
# Retrieve a specific table trigger by ID
Source: https://docs.xano.com/api-reference/table-trigger/retrieve-a-specific-table-trigger-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/table/trigger/{trigger_id}
Retrieve a specific table trigger by ID
Authentication: required
# Retrieve all table triggers
Source: https://docs.xano.com/api-reference/table-trigger/retrieve-all-table-triggers
/apispec_meta_instance.json get /workspace/{workspace_id}/table/trigger
Retrieve all table triggers
Authentication: required
# Update table trigger using XanoScript
Source: https://docs.xano.com/api-reference/table-trigger/update-table-trigger-using-xanoscript
/apispec_meta_instance.json put /workspace/{workspace_id}/table/trigger/{trigger_id}
Update table trigger using XanoScript
Authentication: required
# Configure table security rules
Source: https://docs.xano.com/api-reference/table/configure-table-security-rules
/apispec_meta_instance.json put /workspace/{workspace_id}/table/{table_id}/security
Configure table security rules by assigning an API group GUID or removing restrictions
Authentication: required
# Create a new database table with optional schema definition
Source: https://docs.xano.com/api-reference/table/create-a-new-database-table-with-optional-schema-definition
/apispec_meta_instance.json post /workspace/{workspace_id}/table
This endpoint can create a complete table in a single API request, as long as all values below are fully fleshed out. If you want to create the table in multiple steps, then just fill out the name field as shown in the example.
# Delete a database table and all its data permanently
Source: https://docs.xano.com/api-reference/table/delete-a-database-table-and-all-its-data-permanently
/apispec_meta_instance.json delete /workspace/{workspace_id}/table/{table_id}
Delete a database table and all its data permanently
Authentication: required
# Retrieve all tables in a workspace
Source: https://docs.xano.com/api-reference/table/retrieve-all-tables-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/table
Retrieve all tables in a workspace
Authentication: required
# Retrieve detailed information for a specific table
Source: https://docs.xano.com/api-reference/table/retrieve-detailed-information-for-a-specific-table
/apispec_meta_instance.json get /workspace/{workspace_id}/table/{table_id}
Retrieve detailed information for a specific table
Authentication: required
# Update a workspace table
Source: https://docs.xano.com/api-reference/table/update-a-workspace-table
/apispec_meta_instance.json put /workspace/{workspace_id}/table/{table_id}
update workspace table
Required API Scope:
Workspace Database: Update
# Update table properties
Source: https://docs.xano.com/api-reference/table/update-table-properties
/apispec_meta_instance.json put /workspace/{workspace_id}/table/{table_id}/meta
Update table properties including name, description, tags, and authentication settings
Authentication: required
Required API Scope:
Workspace Database: Update
# Create a new scheduled task using XanoScript
Source: https://docs.xano.com/api-reference/task/create-a-new-scheduled-task-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/task
Create a new scheduled task using XanoScript
Authentication: required
# Delete a scheduled task permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/task/delete-a-scheduled-task-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/task/{task_id}
Delete a scheduled task permanently. This action cannot be undone
Authentication: required
# Retrieve a specific scheduled task by ID
Source: https://docs.xano.com/api-reference/task/retrieve-a-specific-scheduled-task-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/task/{task_id}
Retrieve a specific scheduled task by ID
Authentication: required
# Retrieve all scheduled tasks in a workspace
Source: https://docs.xano.com/api-reference/task/retrieve-all-scheduled-tasks-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/task
Retrieve all scheduled tasks in a workspace
Authentication: required
# Update a scheduled task
Source: https://docs.xano.com/api-reference/task/update-a-scheduled-task
/apispec_meta_instance.json put /workspace/{workspace_id}/task/{task_id}
Update task code, schedule settings, and activation status
Authentication: required
# Create a new tool using XanoScript
Source: https://docs.xano.com/api-reference/tool/create-a-new-tool-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/tool
Create a new tool using XanoScript
Authentication: required
# Delete a tool permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/tool/delete-a-tool-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/tool/{tool_id}
Delete a tool permanently. This action cannot be undone
Authentication: required
# Retrieve a specific tool by ID
Source: https://docs.xano.com/api-reference/tool/retrieve-a-specific-tool-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/tool/{tool_id}
Retrieve a specific tool by ID
Authentication: required
# Retrieve all tools in a workspace
Source: https://docs.xano.com/api-reference/tool/retrieve-all-tools-in-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/tool
Retrieve all tools in a workspace
Authentication: required
# Update a tool
Source: https://docs.xano.com/api-reference/tool/update-a-tool
/apispec_meta_instance.json put /workspace/{workspace_id}/tool/{tool_id}
Update tool code, metadata, and caching settings
Authentication: required
# Update tool security settings
Source: https://docs.xano.com/api-reference/tool/update-tool-security-settings
/apispec_meta_instance.json put /workspace/{workspace_id}/tool/{tool_id}/security
Update tool security configuration and access controls
Authentication: required
# Add a workflow test
Source: https://docs.xano.com/api-reference/workflow_test/add-a-workflow-test
/apispec_meta_instance.json post /workspace/{workspace_id}/workflow_test
add workspace workflow test
Authentication: required
# Delete a workflow test
Source: https://docs.xano.com/api-reference/workflow_test/delete-a-workflow-test
/apispec_meta_instance.json delete /workspace/{workspace_id}/workflow_test/{workflow_test_id}
delete workspace workflow test
Authentication: required
# Retrieve a workflow test
Source: https://docs.xano.com/api-reference/workflow_test/retrieve-a-workflow-test
/apispec_meta_instance.json get /workspace/{workspace_id}/workflow_test/{workflow_test_id}
get workspace workflow test
Authentication: required
# Retrieve all workflow tests
Source: https://docs.xano.com/api-reference/workflow_test/retrieve-all-workflow-tests
/apispec_meta_instance.json get /workspace/{workspace_id}/workflow_test
browse workspace workflow tests
Authentication: required
# Update a workflow test
Source: https://docs.xano.com/api-reference/workflow_test/update-a-workflow-test
/apispec_meta_instance.json put /workspace/{workspace_id}/workflow_test/{workflow_test_id}
update workspace workflow test
Authentication: required
# Update workflow test security settings
Source: https://docs.xano.com/api-reference/workflow_test/update-workflow-test-security-settings
/apispec_meta_instance.json put /workspace/{workspace_id}/workflow_test/{workflow_test_id}/security
update workspace workflow test security settings
Authentication: required
# Create a new external data source with custom label and color
Source: https://docs.xano.com/api-reference/workspace-datasource/create-a-new-external-data-source-with-custom-label-and-color
/apispec_meta_instance.json post /workspace/{workspace_id}/datasource
Create a new external data source with custom label and color
Authentication: required
Required API Scope:
Instance Workspace: Create
# Delete a data source permanently. This action cannot be undone.
Source: https://docs.xano.com/api-reference/workspace-datasource/delete-a-data-source-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/datasource/{label}
Delete a data source permanently. This action cannot be undone.
Authentication: required
Required API Scope:
Instance Workspace: Delete
# Retrieve all external data sources for a workspace
Source: https://docs.xano.com/api-reference/workspace-datasource/retrieve-all-external-data-sources-for-a-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}/datasource
Retrieve all external data sources for a workspace
Authentication: required
Required API Scope:
Instance Workspace: Read
# Update an existing data source's label and color properties
Source: https://docs.xano.com/api-reference/workspace-datasource/update-an-existing-data-sources-label-and-color-properties
/apispec_meta_instance.json put /workspace/{workspace_id}/datasource/{label}
Update an existing data source's label and color properties
Authentication: required
Required API Scope:
Instance Workspace: Update
# Create a new workspace trigger using XanoScript
Source: https://docs.xano.com/api-reference/workspace-trigger/create-a-new-workspace-trigger-using-xanoscript
/apispec_meta_instance.json post /workspace/{workspace_id}/trigger
Create a new workspace trigger using XanoScript
Authentication: required
# Delete a workspace trigger permanently. This action cannot be undone
Source: https://docs.xano.com/api-reference/workspace-trigger/delete-a-workspace-trigger-permanently-this-action-cannot-be-undone
/apispec_meta_instance.json delete /workspace/{workspace_id}/trigger/{trigger_id}
Delete a workspace trigger permanently. This action cannot be undone
Authentication: required
# Retrieve a specific workspace trigger by ID
Source: https://docs.xano.com/api-reference/workspace-trigger/retrieve-a-specific-workspace-trigger-by-id
/apispec_meta_instance.json get /workspace/{workspace_id}/trigger/{trigger_id}
Retrieve a specific workspace trigger by ID
Authentication: required
# Retrieve all workspace triggers
Source: https://docs.xano.com/api-reference/workspace-trigger/retrieve-all-workspace-triggers
/apispec_meta_instance.json get /workspace/{workspace_id}/trigger
Retrieve all workspace triggers
Authentication: required
# Update a workspace trigger
Source: https://docs.xano.com/api-reference/workspace-trigger/update-a-workspace-trigger
/apispec_meta_instance.json put /workspace/{workspace_id}/trigger/{trigger_id}
Update workspace trigger code, metadata, and caching settings
Authentication: required
# Create a new workspace
Source: https://docs.xano.com/api-reference/workspace/create-a-new-workspace
/apispec_meta_instance.json post /workspace
Create a new workspace
Authentication: required
Required API Scope:
Instance Workspace: Create
# Delete a workspace permanently
Source: https://docs.xano.com/api-reference/workspace/delete-a-workspace-permanently
/apispec_meta_instance.json delete /workspace/{workspace_id}
Delete a workspace permanently
Authentication: required
Required API Scope:
Instance Workspace: Delete
# Export complete workspace data and configuration as an archive
Source: https://docs.xano.com/api-reference/workspace/export-complete-workspace-data-and-configuration-as-an-archive
/apispec_meta_instance.json post /workspace/{workspace_id}/export
Leave the `branch` parameter empty to indicate the current live branch. `password` is optional. If provided, will encrypt the export and will be required when importing the file.
Required API Scope:
Instance Workspace: Read
# Export database table schemas and branch configuration as a file
Source: https://docs.xano.com/api-reference/workspace/export-database-table-schemas-and-branch-configuration-as-a-file
/apispec_meta_instance.json post /workspace/{workspace_id}/export-schema
Leave the `branch` parameter empty to indicate the current live branch. `password` is optional. If provided, will encrypt the export and will be required when importing the file.
Required API Scope:
Instance Workspace: Read
# Generate full workspace context
Source: https://docs.xano.com/api-reference/workspace/generate-full-workspace-context
/apispec_meta_instance.json get /workspace/{workspace_id}/context
generate a full context for a workspace
Authentication: required
Required API Scope:
Instance Workspace: Read
# Import database schema into a new branch with optional deployment
Source: https://docs.xano.com/api-reference/workspace/import-database-schema-into-a-new-branch-with-optional-deployment
/apispec_meta_instance.json post /workspace/{workspace_id}/import-schema
Import database schema into a new branch with optional deployment
Authentication: required
Required API Scope:
Instance Workspace: Read
# Replace workspace content and configuration with imported archive
Source: https://docs.xano.com/api-reference/workspace/replace-workspace-content-and-configuration-with-imported-archive
/apispec_meta_instance.json post /workspace/{workspace_id}/import
If the file is encrypted, the correct `password` is required to decrypt.
Required API Scope:
Instance Workspace: Update
# Retrieve all accessible workspaces for the authenticated user
Source: https://docs.xano.com/api-reference/workspace/retrieve-all-accessible-workspaces-for-the-authenticated-user
/apispec_meta_instance.json get /workspace
Retrieve all accessible workspaces for the authenticated user
Authentication: required
# Retrieve detailed information about a specific workspace
Source: https://docs.xano.com/api-reference/workspace/retrieve-detailed-information-about-a-specific-workspace
/apispec_meta_instance.json get /workspace/{workspace_id}
Retrieve detailed information about a specific workspace
Authentication: required
Required API Scope:
Instance Workspace: Read
# Retrieve workspace-wide OpenAPI spec
Source: https://docs.xano.com/api-reference/workspace/retrieve-workspace-wide-openapi-spec
/apispec_meta_instance.json get /workspace/{workspace_id}/openapi
get workspace-wide OpenAPI (swagger) spec for all API groups
Authentication: required
Required API Scope:
Instance Workspace: Read
# Update an existing workspace
Source: https://docs.xano.com/api-reference/workspace/update-an-existing-workspace
/apispec_meta_instance.json put /workspace/{workspace_id}
Update an existing workspace
Authentication: required
Required API Scope:
Instance Workspace: Update
# Push XanoScript multidoc
Source: https://docs.xano.com/api-reference/xanoscript/push-xanoscript-multidoc
/apispec_meta_instance.json post /workspace/{workspace_id}/multidoc
Authentication: required
# Key Concepts
Source: https://docs.xano.com/before-you-begin/key-concepts
Get a quick primer on the key concepts and terminology that we use throughout the product and documentation to get you started quickly.
***
### 🖥️ Instance
Your Xano instance is the heart of everything you do in Xano. An **instance** is a dedicated server that we manage for you and it contains all of your Xano data, including APIs, databases, user data, and more.
On all of our paid plans, each instance has its own dedicated resources, is always available, and completely isolated from other Xano users. This means that even if, in the rare occurrence that one user experiences an issue with their own Xano backend, it won't impact anybody else.
On our free plan, you are on a shared instance with other Xano users.
***
### 📂 Workspace
In your Xano instance, you can have multiple **workspaces**. Think of a workspace as a separate container for each project you're building in Xano. Your workspaces are completely isolated from each other, but all share the same compute resources provided by your instance.
***
### 🧠 Backend
Think of the backend as the brains of a website or app. It's all the behind-the-scenes action that users don't see. When you're browsing an online store, the backend is figuring out what products to show you, keeping track of your shopping cart, and making sure your payment goes through. It's like the engine room of a ship - not glamorous, but absolutely crucial.
***
### 📱 Frontend
The frontend is everything you see and interact with on a website or app. It's the pretty face that greets you when you land on a page. This includes the layout, colors, buttons, and forms you fill out. A good frontend makes using a website feel smooth and intuitive, like a well-designed cockpit in an airplane. It's all about creating a great user experience.
***
### 🗄️ Database
A database is essentially a digital warehouse for information. It's where websites and apps store all their data in an organized way. Need to look up a customer's order history? That's stored in a database. Want to see all products under \$50? The database has that info too. It's like a super-efficient librarian who can find any piece of information in milliseconds.
***
### 🔌 API
APIs allow different applications to communicate and share data with each other. When you use Google Maps inside another app, that's an API at work. When you click a Buy Now button on Amazon, APIs are firing at all cylinders behind the scenes.
APIs don't have to only be based on user action, either. For example, most websites implement some sort of tracking to ensure that the user experience is as smooth as possible. When you visit these websites, there are API calls being made as you navigate through their frontend.
APIs set the rules for how different pieces of software can talk to each other, making it possible for developers to integrate various services without starting from scratch.
An API has a few main components.
Headers are the configuration that rides along with an API request. They contain information like where the request is coming from and what type of data it contains.
The method, also known as the verb, is assigned to an API to typically dictate the type of operation the API is designed to complete.
* **GET**
* Retrieve data
* **POST**
* Send data
* **PUT / PATCH**
* Update data
* **DELETE**
* Delete data
Please note that when you build APIs in Xano, you can choose the method to apply, giving you full flexibility in exactly what function that API serves. While it isn't always best practice, a DELETE endpoint could technically do nothing but add new data, if it makes sense for your use case.
Query parameters and the request body are kind of the same thing, but sent in an API request in different ways.
* **Query parameters** live as part of the request URL. If the API URL is `https://myapi.com/getThings` and expects you to send a thingId with your request, you would append it to the URL with `?thingId=99`, so your full request URL would be `https://myapi.com/getThings?thingId=99.` You would typically use query parameters for GET and DELETE endpoints.
* **Request Body** is like a set of query parameters, but sent as a JSON object. It's more flexible when sending complex data types, such as lists, nested objects, or files.
In the Xano visual builder, these are known as **inputs**. You can add inputs manually, or add a **Database Link** input to automatically populate and sync all fields from a database table.
The response is whatever the API sends back once it has completed the logic it is meant to perform. An API doesn't necessarily need to deliver a response, but it is typical.
Think of your frontend sending an API request when a user logs in. That API request would probably return information about the user logging in, such as their name, location, or other relevant user data.
A response has a few different pieces, similar to what's included in the request, including **response headers** and a **response body**.
***
## 🏷️ Variables
Variables are like containers or labels that store information you want to use later in a workflow. Think of them as named boxes where you can keep different types of items, such as numbers, words, or lists. You give each box a name so you can easily find and use the information it holds whenever you need it in your project. This makes it simple to update or change the data without needing to rewrite everything.
Variables are temporary and exist only while a workflow is running, used for storing information you need to access quickly, whereas values in a database are like records in a filing cabinet, stored permanently until you decide to update or delete them, accessible across various workflows and sessions. This makes databases ideal for managing large sets of data over time, and variables more appropriate for temporary data handling.
***
### 🗃️ JSON
JSON is a handy way of formatting data that's easy for both humans and computers to understand. JSON organizes information into simple key-value pairs, kind of like a really well-structured grocery list. It's lightweight and flexible, which is why developers love using it to pass data between servers and web applications.
For an example of how JSON can supercharge your data structure, take this example of a hand-written grocery list compared to a JSON equivalent.
```json theme={null}
[
{
"category": "Dairy",
"items": [
"Eggs",
"Milk",
"Cheddar cheese"
]
},
{
"category": "Bakery",
"items": [
"Bread"
]
},
{
"category": "Meat",
"items": [
"Chicken breast",
"Ground beef"
]
},
{
"category": "Household",
"items": [
"Candles",
"Laundry detergent"
]
},
{
"category": "Grains",
"items": [
"Rice"
]
},
{
"category": "Supplements",
"items": [
"Protein powder"
]
},
{
"category": "Produce",
"items": [
"Grapes"
]
}
]
```
JSON follows a structure of `key: value` pairs. The key typically defines what the value represents, and the value is the actual value itself.
While it may seem similar, **JSON is not code**. It is just a standard way to structure data. For a real-world comparison, maybe you have a favorite news site or blog that you visit daily. You are used to the format they provide so the information is easily digestible. Now, imagine if every day, they decided to follow a different, unorganized structure instead. This is why data standardization is important, and JSON is a very effective way of achieving this.
#### 📄 Objects
An object represents the whole of a thing, such as a person, place, vehicle, form submission -- the possibilities are endless and fully dependent on what you are building. A JSON object can have multiple keys and values inside.
Here is an example of a JSON object that represents user data.
```json theme={null}
{
"name": "John Doe",
"age": 30,
"city": "New York",
"isStudent": false
}
```
As you can see, we have our **keys**, such as `name`, `age`, and `city`, as well as our values, which are the actual data that belongs to this user.
#### 📑 Arrays
JSON can also represent lists of items, like the example below. It looks almost exactly the same, but now we have multiple people inside of an **array**, or list, denoted by square brackets.
```json theme={null}
[
{
"name": "John Doe",
"age": 30,
"city": "New York",
"isStudent": false
},
{
"name": "Jane Smith",
"age": 25,
"city": "San Francisco",
"isStudent": true
},
{
"name": "Bob Johnson",
"age": 35,
"city": "Chicago",
"isStudent": false
}
]
```
#### Nested Data
Values don't just have to be single items, such as a person's name or email. You can also supply other objects or arrays for your values. In the below example, we've added an interests key and supplied an array of text strings for the value.
```json theme={null}
{
"name": "John Doe",
"age": 30,
"city": "New York",
"isStudent": false,
"interests": ["tennis",
"visual development",
"pizza"]
}
```
### ℹ️ JSON Data Types
You may have noticed a few mentions of things like integers or strings when learning about JSON. It is important to know what types of data are valid representations inside of a JSON object. One of the most important things to remember when working with JSON is that quotation marks are incredibly important and can be the difference between something working or falling apart.
🔤 **Strings** are surrounded by "quotation marks" and are just plain text.
```json theme={null}
{
"name": "John Doe"
}
```
🔢 **Integers** are numbers that are not decimals. Notice how we do not have quotation marks around `1994` in the example below. If we used `"1994"` instead, this would become a string.
```json theme={null}
{
"year": 1994
}
```
🔢 **Decimals **are numbers that contain a decimal point.
```json theme={null}
{
"price": 9.99
}
```
✅ **Booleans** are true or false values.
```json theme={null}
"exists": true
```
⛔ **Null **is a special data type that represents nothing in situations where you need to specify that nothing is provided.
```json theme={null}
"phone": null
```
📑 **Arrays** are lists of things. These could be any other valid JSON data type. You could even have an array of arrays if you wanted.
```json theme={null}
[
"red",
"blue",
"green"
]
```
📄 **Objects** are collections of key-value pairs enclosed in curly braces. Keys are always strings, but values can be any valid JSON data type.
```json theme={null}
{
"name": "John Doe",
"age": 30,
"city": "New York",
"isStudent": false
}
```
# Navigating Xano
Source: https://docs.xano.com/before-you-begin/navigating-xano
### Signing Up
Sign up for an account at [https://xano.com](https://xano.com). Check out the interactive tutorial below to see how it works!
### Logging In
To log in to your Xano account, navigate to [https://app.xano.com/login](https://app.xano.com/login) and login using your username and password or secure sign-on.
### The Basics
Learn the basics of navigating around Xano with the interactive tutorial below.
### What's next?
Looking for specific guidance on navigating and using specific features? Head to that section of the documentation for more information and interactive walkthroughs.
If you want to take a more dedicated learning path through the documentation, you can check out our different learning paths
# Set Up A Free Xano Account
Source: https://docs.xano.com/before-you-begin/set-up-a-free-xano-account
Let's make sure that you are ready to play around in Xano before continuing.
First, let's make sure you have a Xano account. Choose an option below to get started.
For most users, you should start here! Our free plan is almost fully featured and perfect for checking out Xano.
**What do I get with a free account?**
* • One workspace to start your Xano journey
* • A rate-limited backend, perfect for trialing and testing
* • Up to 100,000 records
If you already know you'll need more, sign up for a paid plan today to start with more power and more features.
**What do I get with a paid plan?**
* • Unlimited records
* • No rate limit
* • Team collaboration features
* • Background tasks, workflow testing, middleware, triggers, & more
Once you're in, let's make sure you've went through the workspace setup. Don't worry about not picking the right options; you can always change things later. Check out the interactive tutorial below for a full walkthrough.
# The Development Life Cycle
Source: https://docs.xano.com/before-you-begin/the-development-life-cycle
Learn more about the fundamentals of application development and the software development life cycle.
Before you start building, we wanted to share some best practices around how to think about creating your product or service. If you don't need to learn this, you can go straight to [setting up your Database](/the-database/designing-your-database).
When you have an idea for an app or a project that you'd like to build, it's easy to feel overwhelmed and not even know where to begin. Regardless of whether you're on your own or with a team, it's important to have a framework around how you approach designing, launching, and maintaining your application. Luckily, when building in Xano, you can leverage a tried and tested methodology called the **Software Development Life Cycle (SDLC)**.
**There are** **six phases **to the Software Development Life cycle**,** and Xano was designed to support you and your team through each one.
The first stage of the SLDC usually consists of two parts: **planning** and **analysis**. Gather requirements passively or actively from potential customers or other relevant stakeholders, and ensure you are solving a real problem. You would then be able to analyze the feasibility of creating the product, revenue potential, cost, and more.
Once you decide what you're building is in line with stakeholder goals, addresses user needs, and is feasible to create, you can move to the second stage.
The design phase is where you start to put your ideas to paper. This might include creating actual designs in a tool like [Figma](https://www.figma.com/), or going higher level and using a tool like [Miro](https://miro.com/) to create a wireframe or flowchart. From a Xano perspective, this is where you would start designing a data model.
With a solid foundation to work with, this phase is where the actual development happens and where you turn specifications and designs into an actual product. This phase usually takes the most time, so setting expectations with yourself and the stakeholders you are working with is important.
Xano helps accelerate this stage with features like:
* [Generation of API CRUD Operations](/the-function-stack/building-with-visual-development/apis)
* [Auto-Documentation](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation)
* [Real-time Collaboration](/team-collaboration/realtime-collaboration)
If you're working with a team, you can leverage Xano features like [real-time collaboration](/team-collaboration/realtime-collaboration) to seamlessly work within the same workspace, or create [Branches and Merge](/team-collaboration/branching-and-merging) them in when you're ready to move to the testing phase.
Before launching any product or service, it's important to have everything tested. At this phase, you would have a quality assurance (QA) team step in to run tests, but if you're on your own, you'll need to think through every part of testing your product which is more than just fixing critical bugs.
This might sound easier than it seems, but it's essential to test all the different permutations and ways that your users might interact with your application. Here are some different types of testing that you can do in this phase.
* **Performance testing** Is your product ready to handle the traffic/storage requirements?
* **Functional testing** Does your application meet the requirements set for in the Planning/Analysis phase?
* **Security testing** Is your data in a secure place, and do you meet the appropriate compliance certifications within your country, or if you're dealing with sensitive data?
* **Unit testing** Does every part of your app work the way it's supposed to?
* **Usability testing** Do your users actually understand how to use your app?
**Xano provides a few features to help you in this phase**. Using [Unit Tests](/testing-debugging/unit-tests), [Test Suites](/testing-debugging/test-suites) and [Data Sources](/the-database/database-basics/data-sources) can help you use dummy data without affecting what will be live in production. We support drafts to help you and your team get things right before Publishing. [Branches](/api/branches-and-merging) can be used to create separate testing environments (Development, Staging, Production). For more complex use cases, Xano also supports [Xano Link](/enterprise-plan/xano-link), which allows you to keep all of your Workspaces and Instances in sync with a master so your customers have a consistent experience.
The Deployment stage is where your product or service is shipped to its intended user(s). This process can depend on the nature of what is being released; however, it's best practice to launch to a small set of users (typically called a canary release).
Maintenance is typically the last stage of the SDLC; however, in today's world, people are moving toward a more [Agile software development](https://monday.com/blog/rnd/agile-sdlc/) approach where the product or service is continually improved, and sometimes the feedback from users makes it necessary to go back to the first step of the SDLC. This is why most images of the SDLC that you find are circular because it is a process that keeps repeating itself once you find something that's working.
# Using These Docs
Source: https://docs.xano.com/before-you-begin/using-these-docs
Throughout this documentation, we will be focusing on building a complete backend as an example. As you progress, you'll be able to follow along and build with us.
Before you dive in, let's check out some of the ways you'll learn about Xano using these docs.
### Text Content
The bread and butter of our documentation; we have a ton of content here for you to read and follow along with in product.
***
### Quick Summary / Definitions
Review quick definitions and summaries of the documentation you're viewing, and keep scrolling if you wish for the full version.
***
### Videos
A majority of our functions, features, and use cases have accompanying video content which you can review right alongside our documentation, or save for later viewing.
***
### Interactive Demos
We've included interactive demos that allow you to get a feel for the experience you're reading about without leaving the documentation at all. Try the one above to see how it works!
***
### Actions
If you see this image anywhere, that means there is a Xano Action available for that piece of documentation. For example, if we are walking you through how to build a multi-step function, we might provide an Action alongside it that you can review, interact with, and even import into your Xano account to use right away.
***
### Build Along Examples
Nice job! Look out for these in the documentation so you can build along with us!
If you see the above in any piece of our documentation, it means that there is another opportunity for you to try out that function or feature yourself by building or iterating on the Online Bookstore example. Just click the > icon to expand the content.
It's recommended that you create a new workspace to contain this sample project if you'd like to follow along. Check out the interactive demo below to see how to create a new workspace. For users on our free plan, you can use your existing workspace.
***
### Annotations
Every now and then, we might mention a term that, if you're following the documentation in order, you might not have heard yet. We don't want to take a hard left turn and bring you to a full lesson yet, but you can click on any term that looks like this to get a quick bit of more information or context.
# Where Should I Start?
Source: https://docs.xano.com/before-you-begin/where-should-i-start
## I'm completely new to software development
That's okay! You've made the right choice by coming to Xano. We pride ourselves on providing a holistic development experience without you feeling like you're underwater.
Just click the links in each step to head that direction and get started.
[Key concepts](/before-you-begin/key-concepts)
[Set up your Xano account.](/before-you-begin/set-up-a-free-xano-account)
This is a great time to learn more about the [Software Development Life Cycle](/before-you-begin/the-development-life-cycle), but it's not required to get going.
As you're setting up your account, you'll be prompted to create your first workspace. Getting started with AI is an awesome and quick way to get started fast.
[database](/the-database/database-basics) and [visual builder](/the-function-stack/building-with-visual-development).
You can speak to us via support chat in the lower-left corner of the product, or on the [Xano Community.](https://community.xano.com)
## I'm an experienced developer or technical person
Welcome! We're glad you're here. Xano makes it easy for someone familiar with development and technical concepts to get comfortable quickly while still enjoying the benefits of a visual development platform.
[Xano Database](/the-database/database-basics)
[Visual Builder](/the-function-stack/building-with-visual-development)
[work with data](/building/logic/working-with-data)
* [Lambda Functions](/the-function-stack/functions/apis-and-lambdas/lambda-functions)
* [External API Request](/the-function-stack/functions/apis-and-lambdas/external-api-request)
* [Team Collaboration](/team-collaboration/realtime-collaboration)
* [Direct Database Connector](/xano-features/instance-settings/direct-database-connector)
# Browse Snippets
Source: https://docs.xano.com/browse-snippets
# Chatbots
Source: https://docs.xano.com/building-backend-features/chatbots
Intro to LLMs in Xano
Build a Chatbot with ChatGPT & Xano
***
## Building a Chatbot with OpenAI/ChatGPT and Xano
This guide will walk you through building a chatbot using ChatGPT and Xano.
Before we begin, it's important that you understand the following key concepts:
[Database Basics](/the-database/database-basics)
[Building with Visual Development](/the-function-stack/building-with-visual-development)
[APIs & Lambdas](/the-function-stack/functions/apis-and-lambdas)
[User Authentication & User Data](/building-backend-features/user-authentication-and-user-data)
You should know how to build a database table, build basic function stacks, work with user authentication, and utilize the External API Request function.
***
**Objective:** To create a chatbot, you'll primarily use OpenAI's chat completions API endpoint.
**Endpoint:** The specific endpoint is `/v1/chat/completions`. You'll make `POST` requests to this endpoint.
**Authentication:** All requests to the OpenAI API require authentication. This is done by including an `Authorization` header with a bearer token (your OpenAI API key).
**Request Body:**
* `model`: Specifies which OpenAI model to use (e.g., `gpt-3.5-turbo`). You can find compatible models in the [OpenAI documentation](https://platform.openai.com/docs/models).
* `messages`: This is a crucial part. It's an *array* containing the *entire* conversation history. Unlike interacting directly with ChatGPT, the API requires you to send all previous messages in each request.
* **Message Object Structure**: Each object in the `messages` array needs a `role` and `content`:
* `role`: Defines who sent the message.
* `system`: Sets the initial context or persona for the chatbot (the first "training" prompt).
* `user`: Represents messages sent by the end-user interacting with the bot.
* `assistant`: Represents messages sent *by* the chatbot (responses from the API).
* `content`: The actual text of the message.
**Benefits of Sending Full History:** This allows for fine-tuning or guiding the conversation by potentially modifying or constructing messages within the history you send to the API.
**Other Parameters:** There are optional parameters like `temperature`, but they aren't required to get started.
**User Table:** Create at least one test user for authentication purposes later.
**Conversation Table (**`conversation`**)**: This acts as the parent table. Add the following fields:
* `name` (Type: text): To easily identify conversations.
* `model` (Type: text): To store which OpenAI model is used for this conversation (e.g., "gpt-3.5-turbo").
* `user_id` (Type: Table Reference -> `user`): To link the conversation to the user who initiated it.
**Messages Table (**`messages`**)**: This stores individual messages. Add the following fields, mirroring the structure needed for the OpenAI API request:
* `role` (Type: text): Stores "system", "user", or "assistant".
* `content` (Type: text): Stores the actual message text.
* `index` (Type: integer): A number to track the order of messages within a conversation (0, 1, 2, ...). This is crucial for sorting messages correctly for display and for sending them in the right order to the API.
* `conversation_id` (Type: Table Reference -> `conversation`): To link the message back to its parent conversation.
**API Group:** Navigate to your API groups in Xano. You can use the default group or create a new one.
**New API Endpoint:** Add a new API endpoint. Choose "Start from scratch" or "Custom". Name it something descriptive, like `send_message_to_openai`.
**Inputs:** Define the necessary inputs for this endpoint. You'll likely need:
* `conversation_id` (Input Type: Table Reference -> `conversation`): To know which conversation this message belongs to.
* `user_message` (Input Type: text): The new message typed by the user.
**Function Stack:** This is where the logic happens using Xano's visual builder.
1. **Get OpenAI API Key:** Securely retrieve your OpenAI API key. Store it in Xano's [Environment Variables](/the-function-stack/environment-variables) for security rather than hardcoding it.
2. **Get Conversation History:**
* Add a `Query All Records` step for the `messages` table.
* Filter by the input `conversation_id`.
* **Sort** by the `index` field in ascending order. This ensures messages are retrieved chronologically.
3. **Add User's New Message to History (Temporary):** Add the incoming `user_message` to the list/array of messages retrieved in the previous step. Make sure it has the correct format: `{ "role": "user", "content": user_message }`.
4. **Add External API Request:** This is the core step to call OpenAI.
* Click the "+" button in the function stack and select "External API Request".
* **Import cURL:** Use the OpenAI documentation's cURL example for the chat completions endpoint. Copy the cURL command and use Xano's "Import cURL" feature. This will pre-fill most settings.
* **URL:** Should be `https://api.openai.com/v1/chat/completions`.
* **Method:** `POST`.
* **Headers:**
* Ensure `Content-Type` is `application/json`.
* Add the `Authorization` header. The value should be `Bearer YOUR_API_KEY`, replacing `YOUR_API_KEY` dynamically using the environment variable retrieved in step 1. Use Xano's concatenation filters or sprintf for this.
* **Parameters/Body:**
* Set `model` to your desired model (e.g., "gpt-3.5-turbo"). You could make this dynamic based on the `conversation` record if needed.
* Set `messages` to the *full* conversation history array you prepared in step 3 (including the new user message).
5. **Process API Response:** The response from OpenAI will contain the assistant's reply. You'll typically find it in `response.result.choices[0].message.content`. Add steps to extract this content.
6. **Store Messages in Database:**
* Add a `Add Record` step for the `messages` table to save the *user's* new message. Include `conversation_id`, `role` ("user"), `content` (`user_message`), and the next `index` number.
* Add another `Add Record` step for the `messages` table to save the *assistant's* response. Include `conversation_id`, `role` ("assistant"), `content` (the extracted response), and the subsequent `index` number.
7. **Response:** Define what the Xano API endpoint should return to your frontend (e.g., the assistant's message content, or the updated full conversation).
Call the Xano API endpoint (`send_message_to_openai`) from your frontend application whenever a user sends a message.
Pass the `conversation_id` and the `user_message`.
Display the conversation history, potentially fetching it separately using the auto-generated Xano [CRUD endpoints](/the-function-stack/building-with-visual-development/apis#auto-generated-apis) for the `messages` table, ensuring you sort by the `index` field.
# Custom Report Generation
Source: https://docs.xano.com/building-backend-features/custom-report-generation
## Report Generation using Database Views
Xano offers an easy way to share read-only views of your database tables. If the data is already presented in a readable format, you can quickly share it with others, even if they are not Xano users.
Database View
## Report Generation in the Function Stack
Sometimes, your data may not be in what would be considered a human readable format, and you need to make modifications to it, or present it in an alternative format.
### Using APIs
If you need reports to be generated on demand, use an API endpoint for this functionality.
APIs
### Using Background Tasks
If you want to generate reports based on a schedule, utilize a background task.
Background Tasks
### Key Functions and Concepts
For most report generation, you'll want to ensure familiarity with the following concepts, depending on your specific needs.
For retrieving data from your database
For iterating through retrieved records and transforming the data
Filters are typically used to apply modifications to pieces of data, such as math operations or comparing values.
# Emails
Source: https://docs.xano.com/building-backend-features/emails
**Hint**
If you haven't already, we recommend becoming familiar with these basic concepts before continuing.
* [Working With Data](/the-function-stack/building-with-visual-development/working-with-data)
* [External API Requests](/the-function-stack/functions/apis-and-lambdas/external-api-request)
## Use a Pre-built Action
Xano Actions are available for you to import directly into your workspace and enable email features, such as using Postmark.
Click on any of the Actions below to try it out and add it to your workspace.
Never used an Action before? Check out our docs
[here](/xano-actions/what-are-actions).
Quickly send transactional emails through Brevo with a single API call.
Deliver bulk emails reliably using Postmark’s batch sending capability.
Send beautifully formatted emails with Postmark templates.
Trigger a one-off transactional email using Postmark.
## In the Marketplace
In the Xano Marketplace, several messaging templates are available.
If you don't have the Marketplace enabled, use the steps below to enable it.
Click the icon in the upper-right corner to open **Settings**.
You should now see **Marketplace** available from the sidebar footer.
**Why is the Marketplace not enabled by default?**
We are in the process of phasing out this version of the Marketplace in favor of Xano Actions and related features. You can still use the Marketplace, and anything you utilize there will not disappear, but please note that some Marketplace extensions may not be up to date. We're working hard to bring you a better experience here.
## Build Your Own
You can also build your own messaging functions by using our [External API Request](/the-function-stack/functions/apis-and-lambdas/external-api-request) function and following the API documentation available for your service of choice. Some popular options are linked below for your convenience.
[**MailChimp**](https://mailchimp.com/developer/)
[**Mailtrap**](https://api-docs.mailtrap.io/)
[**Mailgun**](https://documentation.mailgun.com/docs/mailgun/user-manual/get-started/)
# Fuzzy Search
Source: https://docs.xano.com/building-backend-features/fuzzy-search
Xano offers robust search capabilities, commonly referred to as *fuzzy search*, that you can utilize while querying records in a function stack. This includes normalization of words (ie. party vs parties), case-insensitive support, flexible expressions (words, phrases, and negations), and weighted priorities (ie. title vs description) for relevance.
The following demonstrates how to set up search in your database, the logic behind the search functionality, and best practices for utilizing search queries.
[**Watch more videos on Fuzzy Search**](https://www.youtube.com/results?search_query=xano+fuzzy+search+)
### **Creating a Search Index**
First, create an [index](/the-database/database-performance-and-maintenance/indexing). Indexes are used to quickly locate data without having to search every row in a database table every time a database table is accessed. An index is used to define which fields of the database table you want to search. You can even build multiple search indexes on the same table to build different search criteria. For example, if you have both public and private data in the same table, you can build a "normal user" and an "administrator" search.
To create an index, click **Indexes** at the top of the table you would like to build search for, and then click **Create Index.**
Choose **search** as the index type, and give the index a name. Next, specify the language for the data you are searching, the fields you are searching, and the ranking order of the fields being searched.
In this example, we created a new search index on a database of movies called **search\_movies**, in English, and are searching two fields in that database: title and overview. The title field will rank higher than data in the overview field in the qualified search results.
Once ready, click **Save** and Xano will build your index. This can take a few minutes depending on the volume of data of the table.
### Building a Search API
After generating the index, it can be implemented it into a query in the function stack. Use the **Custom Query** feature in the **Filter** tab of the [**Query All Records**](/the-function-stack/functions/database-requests/query-all-records) function.
When adding a custom query, the newly created index is available in the expression builder, noted by the **\$** symbol. It is also labeled as *search* underneath the name.
Next, set the operator to **search** and specify the search query. In this example, we are using an input called **search\_query.**
Congratulations! 🥳 You've just implemented super-fast search inside your function stack.
### Ranking
You can implement a ranking system and sort the search results by this rank for more precise search results. To do this, go to the **Output** tab of the **Query All Records** function, add an **eval** on the search index, and apply the **search\_query** filter. This tells Xano to "use my search index to generate a ranking score of my results based on my search query".
After, add a sort to the query using the newly created eval (in this example, called "rank"). You may also consider to enable paging especially on larger queries.
Add a Sort to the Query by clicking on the Return portion of the Output tab.
Order by in descending order will provide the most relevant search results first.
### Different Search Methods
Search queries can be written in different ways to fulfill specific search requirements.
1. Words separated by a space imply an AND. **Example:** A query of *"toy story"* means *search for toy AND story*
2. Exact phrase searches are possible using double quotes. **Example:** If you wanted to search for *"Toy Story"* as an exact match, your query would be *"Toy Story" with the quotation marks*. **Note:** if you are entering this search expression directly into a JSON payload, then you may need to escape the quotes with a backslash. example: `{"search": "\"Toy Story\""}`
3. Partial phrase matching **Example:** `"Toy * Story"` would return any results that contain Toy Story with one word in between. `"Toy *** Story"` would return any results that contain Toy Story with three words in between.
4. Wildcard matching **Example:** `Sto:*` would return any results that contain words that start with sto.
5. Expression groups **Example:** `(Woody or Buzz) Toy` would return multiple matches for the word Toy that also include either Woody or Buzz.
6. Negation of specific words is possible by using a - character. **Example:** If you wanted to search for movies that have *Toy* in the title, but not *Toy Story*, your query would be `"toy -story"`.
7. You can also use a combination of these to get even more specific. **Example:** Searching for `"toy story" day -night` would mean *search for the phrase Toy Story and the word day, without the word night.*
8. Priority targets allow you to specify which priority defined in your search index to use for the specific expression. This can be combined with wildcard matching as well. **Example:** `Toy Story:2` would search for all records containing the word Toy, as well as the word Story in any fields representing priority 2 in your search index. **Example:** `Toy Sto:*2` would search for all records containing the word Toy, as well as words starting with Sto in any fields representing priority 2 in your search index.
9. Single vs Plural is supported. For example, *"toy"* will also return results that contain *"toys"*.
**Stop Words** -- are commonly used words such as articles, pronouns and prepositions. For example: *is, and, an, or, the.* Stop words are not included in your search query.
### Search Results
Search results are returned just like any other API response and the data works just like any other variable inside Xano.
# Location Data
Source: https://docs.xano.com/building-backend-features/location-data
# Messaging
Source: https://docs.xano.com/building-backend-features/messaging
**Hint**
If you haven't already, we recommend becoming familiar with these basic concepts before continuing.
* [Working With Data](/the-function-stack/building-with-visual-development/working-with-data)
* [External API Requests](/the-function-stack/functions/apis-and-lambdas/external-api-request)
## Use a Pre-built Action
Xano Actions are available for you to import directly into your workspace and enable messaging features, such as sending Slack messages.
Click on any of the Actions below to try it out and add it to your workspace.
Never used an Action before? Check out our docs [here](/xano-actions/what-are-actions).
[**Send Slack Message**](https://www.xano.com/actions/run/xano/0fQc6LDiLQUS)
[**Send Whatsapp Message**](https://www.xano.com/actions/run/xano/pzGep0choc8a)
## In the Marketplace
In the Xano Marketplace, several messaging templates are available.
If you don't have the Marketplace enabled, use the steps below to enable it.
Click the icon in the upper-right corner to open **Settings**.
You should now see **Marketplace** available from the sidebar footer.
**Why is the Marketplace not enabled by default?**
We are in the process of phasing out this version of the Marketplace in favor of Xano Actions and related features. You can still use the Marketplace, and anything you utilize there will not disappear, but please note that some Marketplace extensions may not be up to date. We're working hard to bring you a better experience here.
## Build Your Own
You can also build your own messaging functions by using our [External API Request](/the-function-stack/functions/apis-and-lambdas/external-api-request) function and following the API documentation available for your service of choice. Some popular options are linked below for your convenience.
[**Facebook Messager / Instagram**](https://developers.facebook.com/docs/messenger-platform/send-messages/)
[**Twilio**](https://www.twilio.com/docs/messaging/api)
# Notifications
Source: https://docs.xano.com/building-backend-features/notifications
# Payments
Source: https://docs.xano.com/building-backend-features/payments
# User Auth & Data
Source: https://docs.xano.com/building-backend-features/user-authentication-and-user-data
## **Enable Authentication for a Table**
Authentication starts with enabling the function on a table that contains user data. Typically, this would just be your `user` table. You can also enable authentication on multiple tables if you want separate authentication methods for different user groups, such as normal users and administrators.
## **Enable Authentication on an API Request**
Once you've enabled authentication on a table, you can use each API endpoint's settings to note whether or not it requires authentication.
When a request is sent to API endpoints that require authentication, an authorization token is sent in the headers of the request, which Xano checks against the table with authentication enabled, before allowing the request to continue.
Still need a primer on the basics of an API? Read more
[here](/before-you-begin/key-concepts#api).
This dropdown will list each table that you have authentication enabled on. Select the table you enabled authentication on.
Once an API has authentication enabled, it will require an authentication token to be sent in the headers of the request.
## How does authentication work?
Authentication in Xano is powered by industry-standard JWE (JSON Web Encryption) tokens.
Once a token is generated (after login or signup), your app or website will send that token back to Xano for requests that require authentication.
A token is generated using the [**Create Authentication Token**](/the-function-stack/functions/security#create-authentication-token) function, and is typically used in conjunction with a standard login or signup authentication flow.
## Adding Pre-built Authentication Endpoints
* **Login**
* Accepts an email or username and password, and allows a user to log in
* **Signup**
* Accepts user information and creates an account for them
* **auth/me**
* Checks an authentication token and returns user information
## Building Sign-up and Login APIs
Below, you can review a **typical** login and signup flow — you are free to modify them to suit your needs. These are the same that Xano can add for you during signup
### Login
First, we need to retrieve the record of the user trying to login.
We use a precondition step to check if a user record was returned in step 1.
If it wasn't, we return an error and halt execution.
Because passwords stored in a Xano database are hashed and not human
readable, we use a Validate Password function to check what the user has
submitted against the password stored in the database. This function returns
a `true` or `false` depending on the result.
We use another precondition step to check if the password was successfully
validated. If not, we return an error and halt execution.
Finally, all checks are passed, and we create and return the authentication
token.
### Signup
Checks if a user record already exists with the provided information.
Checks to see if there is a user record returned in step 1. If so, we halt
execution and return an error
Add a new record for the user in the `user` table
Creates an authentication token to be used in future API requests.
## Extras
The extras payload is an optional setting that allows you to store additional information securely inside the token, such as a user role or other additional information.
When testing endpoints with authentication enabled, the quick token generator
will not include extras or any other customization present in your login or
signup endpoints.
## Refresh Tokens
Refresh tokens are like spare keys for your online accounts. When a user logs in, they are issued an authentication token. This token eventually expires for security reasons, assuming you've specified an expiry time in your Create Authentication Token functions.
Once this token expires, additional user requests will fail and your frontend would probably redirect them back to the login screen. You can utilize refresh tokens to avoid having your users log in again, while maintaining the shorter expiry that is standard for an authentication token. It's a dance of logic between your backend and frontend to make this work as expected.
Below, you'll find a flowchart that details this process, and an interactive tutorial for how to add refresh token support to your Xano backend.
```mermaid theme={null}
flowchart TD
A[User Login] --> B{Valid Credentials?}
B -->|No| C[Login Failed]
B -->|Yes| D[Backend Generates Access Token and Refresh Token]
D --> E[Frontend Stores Both Tokens]
E --> F[User Makes API Request]
F --> G[Frontend Sends Access Token]
G --> H{Auth Token Close to Expiring?}
H -->|Yes| K[Need New Auth Token]
H -->|No| I[API Request Successful]
I --> J[Continue Using App]
J --> F
K --> M[Frontend Sends Refresh Token to /refresh Endpoint]
M --> N{Refresh Token Valid?}
N -->|No - Expired| O[Redirect to Login]
O --> A
N -->|Yes| D
style D fill:#e1f5fe
style K fill:#ffebee
style O fill:#ffebee
```
## Additional Notes
#### Alternative Authentication Headers
If you need to provide a secondary authentication header that takes precedence over the original Xano authentication, you can do so by sending the \*\*X-Xano-Authorization-Only \*\*header along with your requests. This will allow you to move the Xano authentication token to its own header, keeping the original standard **Authorization** header for something else.
You would want to utilize the **X-Xano-Authorization-Only** header if you are sending requests to your Xano APIs from another source that uses the \*\*Authorization \*\*header key for something else on both public and authentication required endpoints that are using the **Authorization** header for something other than Xano authentication.
**Example:**
```sh {1-2} theme={null}
// For a public Xano endpoint that sends an Authorization header
curl "http://localhost:9999/api:elnQNVvy:v1/public_test" \
-H "X-Xano-Authorization-Only: true"
// For a private (authenticated) Xano endpoint that receives an Authorization header
that is not a Xano auth token
curl "http://localhost:9999/api:elnQNVvy:v1/private_test" \
-H "X-Xano-Authorization: Bearer ey...." \
-H "X-Xano-Authorization-Only: true"
```
# OAuth (SSO)
Source: https://docs.xano.com/building-backend-features/user-authentication-and-user-data/oauth-sso
**OAuth** is a security framework that allows you to grant websites or applications access to your information without sharing your password. It acts like a permission slip, letting a service access part of your data from another service on your behalf. For example, you might log into a new app using your Google or Facebook account, and OAuth handles the secure sharing of your data between the services.
## **OAuth vs JWE Token Authentication**
**OAuth** is like giving a valet key to a friend, allowing them limited access to your car. It lets services share your data safely without sharing your password. You're still in control, and you can revoke this access at any time.
**JWE Token Authentication** is more like using a sealed envelope. Your information is encrypted and can only be read by the intended recipient. It ensures data integrity and privacy but doesn't manage who has access like OAuth does. It's great for situations where secure data transmission is key.
## The OAuth Flow
1. **Client Registration**: The client application registers with the OAuth service provider to obtain a client ID and client secret, which are used to identify the application during the OAuth flow.
2. **User Authorization**: The client redirects the user to the authorization server where the user logs in and consents to the application's data access request. This is where the user would see a Google, Facebook, X, or other sign-in option on your frontend.
3. **Authorization Grant**: Once the user signs in and approves access, the authorization server issues an authorization grant to the client, typically in the form of a code sent via a URL query parameter. This would be one of your APIs in Xano that is designed to ingest that authorization.
4. **Access Token Request**: Your Xano API sends a request to the authorization server's token endpoint, including the authorization grant and credentials (client ID and secret), to obtain an access token. Once we've determined that token is valid, it will be traded for a Xano JWE token to proceed with standard authentication methods.
5. **Access Token Response**: The authorization server verifies the request and returns an access token, which the client can use to access protected resources on the user's behalf.
6. **Access Resource**: The client uses the access token to make requests to the resource server, accessing the user's resources as allowed by the token's scope.
## Building OAuth in Xano
If you don't see **Marketplace** in the sidebar footer, click the icon in the upper-right corner to open **Settings**, and enable the Marketplace under **Navigation Preferences**.
Check the box to **Enable Marketplace**
Xano provides several prebuilt OAuth flows that you can import from here into your workspace.
# Restricting Access (RBAC)
Source: https://docs.xano.com/building-backend-features/user-authentication-and-user-data/restricting-access-rbac
RBAC (Role-based access control) or role-based permissions is a way to restrict access based on a user's defined role. This guide will cover two different methods of enforcing access / RBAC to an API endpoint based on the user's role.
Let's use the following user table for both examples of RBAC. Make note of the role field and the values for each user.
#### **RBAC Example 1: Use Get Record**
Now, let's set up an API endpoint that GETs all users but only if the user trying to call the endpoint has a role of admin.
Take note of the endpoint below, user authentication is required. Additionally, take note of the Function Stack:
1. Get Record from user: This will use the authToken to find the user's ID and look up their information.
2. Precondition: This will enforce that the user's role is equal to admin. If it is not, then it will throw and error and stop the endpoint.
3. Query all records from user: This will only be performed if the user's role is an admin by passing the precondition.
Get the record of the user who's calling the endpoint (requester) with the auth ID.
Next, set a precondition to enforce that the user (called requester in the example) has a role equal to admin.
If the precondition is met, then the user who is the requester will have permission to execute the rest of the Function Stack and complete the API endpoint.
#### RBAC Example 2: Use Extras
[Extras](/building-backend-features/user-authentication-and-user-data#extras) allow you to store data within the authentication token, which you can access and use on authenticated API endpoints.
First, you must set up the [sign-up & login](/building-backend-features/user-authentication-and-user-data) to include the user's role at the time of authentication.
In this example, we will use the login endpoint to pass the user's role into extras of the auth token at the time of authentication.
Now that the user's role is passed into the authToken, we can eliminate the Get Record function from the previous example and reference "extras.role" in the precondition to enforce the user's role.
If the user's role is equal to admin then they will pass the precondition and have permission to execute the rest of the Function Stack.
# Separating User Data
Source: https://docs.xano.com/building-backend-features/user-authentication-and-user-data/separating-user-data
Separating and restricting access to data are two common features of building a backend. Separating data is crucial for multi-tenant systems. It means that even though all your users have data in the same table, they are only able to see and access the data that belongs to them.
[Restricting Access](/building-backend-features/user-authentication-and-user-data/restricting-access-rbac) (Role-Based Access Control) takes this to another level if, for example, there are special roles assigned to users like an admin who may have permission to access more data than a standard user. You can read more on restricting access or RBAC by clicking the link at the beginning of this paragraph.
### Separating Data Example 1
For this example, we have three users in our user table: Steph, Klay, and Jordan.
There is also an items table. Each item belongs to a user.
#### How to enforce a user only sees the items that belongs to them
Here we have an API endpoint, which gets all the items from the items table. The first step is to require user [authentication](/building-backend-features/user-authentication-and-user-data) on the endpoint.
Now that authentication is required, the next step is to open the [Query All Records](/the-function-stack/functions/database-requests/query-all-records) function and add an expression to the by custom query section.
```python theme={null}
WHERE
db: items.user_id = auth id
```
When we go to run the API endpoint in Run\&Debug, an auth token is required to run the API. In Xano, we can easily search for a user to use a auth token for testing. In your application, the user will need to [authenticate](/building-backend-features/user-authentication-and-user-data) first by logging in or signing up.
Let's select user 2, Klay and run the API endpoint:
The result is all the items associated with user id = 2:
#### Added layer of security with precondition
We can add an additional layer of security with the use of preconditions.
First, use a Get Record on the user table with a field value of the auth id.
Then use a precondition to enforce the auth ID is equal to the id from the Get Record.
```python theme={null}
WHERE
auth id = var: user.id
```
#### How to enforce the user can only edit data that belongs to them
When it comes to editing data, the function stack will also use a precondition. The API endpoint will once again require authentication.
First, we need to Get the Record of the item that the user wants to edit.
Getting the existing record allows us to check if it belongs to the user.
Next, use a Precondition to say:
```python theme={null}
WHERE
var: items_1 |GET| "user_id" = auth id
```
Here we use the GET filter with a default value of 0. This helps us account for existence of the record we want to edit. If the record does not exist, the precondition will trigger because a user\_id value of 0 will not match the auth ID.
If the precondition passes, then the function stack will continue to run and edit the data. If it fails, it will throw an error and stop execution.
# User Roles
Source: https://docs.xano.com/building-backend-features/user-roles
# Webhooks
Source: https://docs.xano.com/building-backend-features/webhooks
Webhooks are specialized API endpoints designed to be triggered based on other events
**Quick Summary**
Webhooks are API endpoints specifically designed for one system to **automatically push** information to another when a specific **event** happens. For example, Slack provides you with a webhook URL. This URL is ready and listening, much like your own API endpoint.
But here’s the key difference:
1. Something like a **form submission endpoint** receives data because the *user initiated* the request (e.g., they clicked 'Submit').
2. The **Slack webhook** receives data because *your server*, after processing the form (the **event**), *initiated* a new request, automatically pushing the form details *to* Slack's URL. Slack didn't ask for it; your system sent it because something happened.
You'd build webhooks in Xano typically to ingest information ***pushed*** from other places — like if a user pays for something via Stripe, or they perform an action in your app that you want to log.
## Building Webhooks
1. Click + Add API Endpoint from inside one of your API groups.
2. Choose **Custom API Endpoint** and fill in the details. Make sure to select **POST** as the verb.
Typically, webhooks need to be able to dynamically process data that might look a little different between requests. So, we use [Get All Raw Input](/the-function-stack/functions/utility-functions#get-all-raw-input) to make sure that we aren't confined to just the inputs that are defined in the inputs section.
You'll need to choose the encoding, or the format, of the data being sent to this endpoint. This will more often than not be JSON.
While Get All Raw Input offers flexibility, always check the documentation of the service *sending* the webhook. They will specify the structure (schema) of the data payload you should expect.
From here, the process is completely unique to whatever data is being sent to the webhook, and what you need to do with it.
**Examples:**
* Store the data in a database table using [Add Record](/the-function-stack/functions/database-requests/add-record)
* If the webhook is receiving a list of items, loop against them using [For Each Loop](/the-function-stack/functions/data-manipulation/loops#for-each-loop)
* Transform or manipulate the data using [Filters](/the-function-stack/filters) or an [Expression](/the-function-stack/data-types/expression)
* Send the data to another service, such as an analytics platform, using an [External API Request](/the-function-stack/functions/apis-and-lambdas/external-api-request)
* Begin a more in-depth process using a combination of the above to perform multiple actions, such as transforming data, storing it, and sending [Emails](/building-backend-features/emails)
## Securing your Webhooks
Just like any other API endpoint you're building, it's important to ensure that they are built securely. Webhooks have some more specific-to-them ways that they are usually kept locked up.
The service you're accepting requests from may offer signature verification. At a high level, this means that you would cross-check the signature they sent with your own calculated signature, using a private key that only you and the service are aware of, and ensure that they match.
**If they match**: The request is verified and you can proceed.
**If they don't match**: you should deny the request
In general, this process follows a typical flow:
* Extract the signature provided in the request headers
* Ensure you have a raw, unaltered copy of the request body (which you do using Get All Raw Input)
* Use the proper [Security](/the-function-stack/filters/security) filter (such as [hmac\_sha256 / hmac384 / hmac512](/the-function-stack/filters/security#hmac_sha256-hmac384-hmac512)) to encode your own signature, and ensure that it matches with the one you extracted from the request.
Similar to how standard [User Authentication & User Data](/building-backend-features/user-authentication-and-user-data) works, some services may just send an API key or bearer token as part of the request header. You'll want to compare this against your own stored key and ensure that they match.
It's also good practice to rotate this token on a regular basis to ensure that it is not compromised.
**Tip**
Use [Middleware](/building/logic/middleware) or [Custom Functions](/building/logic/custom-functions) to build your webhook verification and quickly deploy it across multiple function stacks.
# Building Visually with the Canvas View
Source: https://docs.xano.com/building/build-visually/canvas-view
Build a workflow without code using the Canvas View
## What is the Canvas View?
The Canvas View is designed to show you your workflow at a high level, in more of a story-based view. It's fully featured for any editing or iteration, but also easier to understand for non-technical members of your team.
## What does the Canvas View look like?
The Canvas displays your entire workflow as a series of nodes, each representing a step in your logic. Some nodes represent major sections, like Inputs or Response, while others represent specific functions, such as fetching a database record or manipulating data. This view makes it easy to understand and modify your logic visually.
## Navigating the Canvas
Canvas View navigation is fully mouse driven and was designed to feel intuitive and natural.
You can reposition nodes by clicking and dragging them. The connecting lines between nodes will automatically adjust, so you never lose sight of your overall flow.
If your layout gets messy, click Auto Layout in the bottom-right corner to reorganize everything into a clean, standard structure. That same panel also includes zoom controls, letting you quickly fit the entire workflow into view.
For additional clarity, you can use the AI description generation feature to automatically create plain-language explanations of each function in your workflow. This is especially useful when sharing complex logic with non-technical team members.
## Building with the Canvas View
To edit an existing node, simply click on it.
For function nodes, a side panel will appear where you can configure its options.
For Inputs and Response, you can edit them directly inside the node by clicking the Add an Input or Add a Response buttons.
To add new steps, hover over a node and click the icon to insert a new function after it. You can also hover over the connecting lines to insert a function at that point in the flow.
Hovering over any node reveals additional actions such as disabling, cloning, and deleting that step.
## What's next?
Learn how deploying your changes to production works
Learn about the core components of building logic
Learn about the Function Stack, a visual first but more code-like building experience
# Function Stack
Source: https://docs.xano.com/building/build-visually/function-stack
Build a function stack in the visual builder
## What is the Function Stack?
The function stack is a hybrid between a traditional code view and a visual builder. It shows you each function in execution order, but in a way that is understandable for non-technical users.
## What does a Function Stack look like?
The Function Stack will be comprised of *up to* three different sections — **inputs**, the **function stack**, and the **response**. Different function stack types may not contain all of the available sections listed below.
## Navigating the Function Stack
The Function Stack can be navigated using mouse or keyboard shortcuts, or both. It's designed to feel similar to a traditional code editor, but with the added benefit of visual development and quick editing.
In the Function Stack view, you’ll see different sections depending on what you’re building.
Each section has “Add” buttons that let you create new items in that area, such as inputs or functions.
You can also hover over an existing function in the function stack and click the icon to insert a new function directly below it. Hovering over any function reveals additional options such as cloning, disabling, or deleting that step.
You can click and drag functions to reorder them within the stack, giving you fine-grained control over execution flow.
To work more efficiently, hold Shift and select multiple functions to perform bulk actions such as disabling, deleting, or copying them to another workflow.
The Function Stack has two different layout modes that can be switched using the toggle right above the stack:
* Comfortable view, which spaces out functions for easy reading.
* Compact view, which condenses the layout for scanning large workflows.
A built-in search bar lets you quickly find functions, variables, or any element in your stack without scrolling.
Prefer working with your keyboard? Xano provides a range of keyboard shortcuts for power users. You can review and customize them from the shortcuts panel directly in the Function Stack view\..
## Building with the Function Stack
Add a function by clicking the Add Function button below the function stack, hover over a function and click the sign, or use your up and down arrow keys to select a row, and press A on your keyboard to add a new function.
Each function will have a different set of options available to you, so it's best to consult that function's specific documentation for more information.
After you add a function, Xano will sometimes suggest the most likely next step; for example, adding a Query All Records will suggest a loop after. You can choose to add the suggestion, ignore it, or just continue working and Xano will dismiss the suggestion automatically.
You can click the icon to tell Xano to never suggest that specific addition again, or to disable suggestions.
## What's next?
Learn how deploying your changes to production works
Learn about the core components of building logic
Learn about the Canvas View, a visual first but more code-like building experience
# API Request Assistant
Source: https://docs.xano.com/building/build-with-ai/api-request-assistant
Learn how to use the API Request Assistant to help build external API requests for your backend
The API Request Assistant can help you build API requests for your backend. Any time you need to make a connection with an external service, you can use this assistant to help build the request for you.
### Using the API Request Assistant
The Assistant has internet access, so it can look up the API documentation for you. In some cases, it may not find the most current version, so you can also just paste the documentation into the Assistant.
You can converse with the Assistant to iterate on the request, or apply the request to the function.
# Database Assistant
Source: https://docs.xano.com/building/build-with-ai/database-assistant
Learn how to use the Database Assistant to help add to or update your database
The Database Assistant can build your entire database with a single prompt, or update your existing database with ease. We've built the assistant to follow best practices for database design, so you can focus on building your application and build with confidence.
You can ask the assistant to:
* Add or update tables
* Critique your database design and make recommendations
* Build an entire database from scratch
* Answer questions about your database (not your data, only the schema)
Once the assistant has taken a first pass at your question, you can continue to converse with it to iterate and expand, or correct missteps.
# Getting Started Assistant
Source: https://docs.xano.com/building/build-with-ai/getting-started-assistant
Learn how to use the Getting Started Assistant to build your Xano workspace
The Getting Started Assistant is a tool that helps you build your Xano workspace by generating a database, tables, user authentication, and even basic API endpoints that you can use right away. With just a prompt, you can go from idea to a fully functional CRUD backend in just minutes.
## Using the Assistant
You can access the Getting Started Assistant every time you create a new workspace.
Once the assistant has taken a first pass at your idea, you can continue to converse with it to iterate and expand, or correct missteps.
You can start over at any time by clicking the **Start Over** button at the bottom-right, next to the **Create** button. **Create** will finalize the new database.
Tables will by default be created with a sequential ID (1, 2, 3, etc...) but you can change this to a UUID by using the selector to the right of the chat box.
Switch between the Table view and the Spreadsheet view to see the schema, or sample records for each table created.
## What's next?
# Lambda Assistant
Source: https://docs.xano.com/building/build-with-ai/lambda-assistant
Learn how to use the Lambda Assistant to help build Lambda functions for your backend
The Lambda Assistant can help you build Lambda functions in JavaScript or TypeScript. In most cases, a Lambda isn't necessary, but it can still be helpful if you want to utilize an NPM package that has functionality Xano doesn't support natively.
### Using the Lambda Assistant
Our Lambda functions use Deno behind the scenes, so it will first present you with some helpful syntax tips to get started, which the Assistant is familiar with as well. You can run your function stack beforehand to give the Assistant access to the context of the rest of your logic.
You can also ask the Assistant to import any NPM packages you need, and it will automatically add the import statement to the top of the function.
Ask the Assistant to build the Lambda function, and it will generate the code for you.
Once the Assistant has taken a first pass at your question, you can continue to converse with it to iterate and expand, or correct missteps.
# Logic Assistant
Source: https://docs.xano.com/building/build-with-ai/logic-assistant
The Logic Assistant can help you build APIs, Custom Functions, and Background Tasks with just a prompt.
### Using the Logic Assistant
The Logic Assistant will think about your question, and first provide a plan of action. Read through the plan and then click **Apply Plan** to continue, or ask the assistant to iterate on it.
# Prompt Assistant
Source: https://docs.xano.com/building/build-with-ai/prompt-assistant
Learn how to use the Prompt Assistant to help build AI system and user prompts
The Prompt Assistant can help you build AI system and user prompts for your backend. It's available when building [AI Agents](/ai-tools/agents).
### Using the Prompt Assistant
The Assistant can help you build prompts for your AI Agent. You can ask the Assistant to build a prompt from scratch, or to modify an existing prompt.
Once the Assistant has taken a first pass at your question, you can continue to converse with it to iterate and expand, or correct missteps.
# SQL Assistant
Source: https://docs.xano.com/building/build-with-ai/sql-assistant
Learn how to use the SQL Assistant to help build complex SQL queries for your database
The SQL Assistant can help you build complex SQL queries for your database. It's useful when utilizing the [Direct Database Query](/the-function-stack/functions/database-requests/direct-database-query) function, or when you need to build a query that isn't supported by the visual [Query All Records](/the-function-stack/functions/database-requests/query-all-records) function.
### Using the SQL Assistant
The Assistant has access to your database (as long as you've accepted the A.I. Assistant terms and conditions), so it can understand queries like "get me all the records from the users table where the age is greater than 30" or "get me all the records from the users table who have placed orders in the last 30 days".
You can also ask the Assistant to build a query from scratch, or to modify an existing query.
Once the Assistant has taken a first pass at your question, you can continue to converse with it to iterate and expand, or correct missteps.
# Template Assistant
Source: https://docs.xano.com/building/build-with-ai/template-assistant
Learn how to use the Template Assistant to help build templates for AI prompts, HTML, and other more large-format data
The Template Assistant can help you build templates for AI prompts, HTML, and other more large-format data without utilizing a bulk of separate functions, and integrating dynamic data from your logic.
### Using the Template Assistant
The Template Assistant has access to context from your logic (as long as you've run it at least once this session), so you can insert your variables, as well as inputs and environment variables, from the panel below the editor. The Assistant can help you build HTML, JSON, XML, markdown, and more, all with dynamic data from the rest of your logic.
# Xano MCP Server
Source: https://docs.xano.com/building/build-with-ai/xano-mcp
Learn how to use the Xano MCP Server with an MCP client to build your entire backend with AI
The Metadata API and MCP Server are experimental and under active development. Using them with AI or automation tools may result in data loss, corruption, or deletion. Do not use in production without full safeguards and backups.
The Xano MCP Server is a collection of tools that you can connect to using your favorite MCP client of choice, to chat with your Xano backend. The MCP server has a great number of tools available to help you build and manage your workspace with AI. Here are just a few examples:
* Create database tables and update table schema
* Generate sample data
* Build APIs, custom functions, background tasks, AI agents, and any other type of logic or workflow
* Gather the OpenAPI spec for your workspace to assist with frontend development
A list of all the tools available in the Xano MCP Server
### Using the Xano MCP Server
Access Tokens are used for authentication when connecting to the Xano MCP server. Head to your [instance selection screen](https://app.xano.com/instance) and click the⚙️ icon next to your instance.
Choose Metadata API & MCP Server, and click Manage Access Tokens.
Click New Access Token.
Give your access token a name, and select the scopes you need. Click Create at the bottom of the panel. You can read more about the scopes in our [Token Scopes Reference](/xano-features/metadata-api/token-scopes-reference).
You'll only be shown your token once, so make sure to copy it and store it in a safe place.
Right now, we recommend using VS Code over other clients. We're working to improve the experience across the board, but in our testing, VS Code has performed the best while using the Xano MCP Server with the ChatGPT 4o model.
You can add an MCP server to a specific project, or to your user configuration to make it available across all projects.
MCP Servers in VS Code require access to Copilot.
### Specific Project Configuration (recommended)
You'll be asked for the URL to connect to your server, which you can find in the MCP Server panel in your instance settings. Use the `streaming` URL.
Then, give VS Code a name for your server.
You'll need to manually add the authentication information for the MCP server. You'll need the access token you generated earlier.
Add a comma after `type`, and then on a new line, add `"headers": {"Authorization": "Bearer token_here"}`.
Save the file.
You can now use the Xano MCP Server in VS Code.
For more details on connecting to MCP servers in VS Code, see the [VS Code MCP Server documentation](https://code.visualstudio.com/docs/copilot/customization/mcp-servers).
```json theme={null}
"": {
"command": "npx",
"args": [
"mcp-remote",
"https://your-instance-url.xano.io/x2/mcp/meta/mcp/sse",
"--header",
"Authorization:${AUTH_TOKEN}"
],
"env": {
"AUTH_TOKEN": "Bearer "
}
}
```
Make sure Agent mode is selected.
You'll now be able to use the Xano MCP server in Cursor.
```json theme={null}
"xano": {
"command": "npx",
"args": [
"mcp-remote",
"https://your-instance-url.xano.io/x2/mcp/meta/mcp/sse",
"--header",
"Authorization:${AUTH_TOKEN}"
],
"env": {
"AUTH_TOKEN": "Bearer "
}
}
```
You can now use the Xano MCP Server in Windsurf.
# Xano MCP Tool filters
Source: https://docs.xano.com/building/build-with-ai/xano-mcp-tool-filters
When connecting to the Xano MCP server, you'll need to select what categories of tools to allow. This guide explains the available tool filter options.
| Tool Name | Type | Tags |
| :------------------------------- | :------------------- | :-------------------------------- |
| `listAgents` | `agent` | `agent`, `ai` |
| `getAgent` | `agent` | `agent`, `ai` |
| `deleteAgent` | `agent` | `agent`, `ai` |
| `createAgent` | `agent` | `agent`, `ai` |
| `updateAgent` | `agent` | `agent`, `ai` |
| `listAgentTriggers` | `agent_trigger` | `agent_trigger`, `ai` |
| `getAgentTrigger` | `agent_trigger` | `agent_trigger`, `ai` |
| `deleteAgentTrigger` | `agent_trigger` | `agent_trigger`, `ai` |
| `createAgentTrigger` | `agent_trigger` | `agent_trigger`, `ai` |
| `updateAgentTrigger` | `agent_trigger` | `agent_trigger`, `ai` |
| `updateAgentTriggerSecurity` | `agent_trigger` | `agent_trigger`, `ai` |
| `listTools` | `tool` | `tool`, `ai` |
| `getTool` | `tool` | `tool`, `ai` |
| `deleteTool` | `tool` | `tool`, `ai` |
| `createTool` | `tool` | `tool`, `ai` |
| `updateTool` | `tool` | `tool`, `ai` |
| `updateToolSecurity` | `tool` | `tool`, `ai` |
| `listMCPServers` | `mcp_server` | `mcp_server`, `ai` |
| `getMCPServer` | `mcp_server` | `mcp_server`, `ai` |
| `deleteMCPServer` | `mcp_server` | `mcp_server`, `ai` |
| `createMCPServer` | `mcp_server` | `mcp_server`, `ai` |
| `updateMCPServer` | `mcp_server` | `mcp_server`, `ai` |
| `documentation` | `mcp_server` | `mcp_server`, `ai` |
| `listMcpServerTriggers` | `mcp_server_trigger` | `mcp_server_trigger`, `ai` |
| `getMCPServerTrigger` | `mcp_server_trigger` | `mcp_server_trigger`, `ai` |
| `deleteMCPServerTrigger` | `mcp_server_trigger` | `mcp_server_trigger`, `ai` |
| `createMCPServerTrigger` | `mcp_server_trigger` | `mcp_server_trigger`, `ai` |
| `updateMCPServerTrigger` | `mcp_server_trigger` | `mcp_server_trigger`, `ai` |
| `updateMCPServerTriggerSecurity` | `mcp_server_trigger` | `mcp_server_trigger`, `ai` |
| `getWorkspaceBranches` | `workspace_branch` | `workspace_branch`, `logic`, `ai` |
| `deleteWorkspaceBranch` | `workspace_branch` | `workspace_branch`, `logic`, `ai` |
| Tool Name | Type | Tags |
| :------------------------------- | :------------------ | :------------------------------- |
| `listFunctions` | `function` | `function`, `logic` |
| `getFunction` | `function` | `function`, `logic` |
| `deleteFunction` | `function` | `function`, `logic` |
| `createFunction` | `function` | `function`, `logic` |
| `updateFunction` | `function` | `function`, `logic` |
| `updateFunctionSecurity` | `function` | `function`, `logic` |
| `listAPIGroups` | `api_group` | `api_group`, `logic` |
| `getApiGroup` | `api_group` | `api_group`, `logic`, `frontend` |
| `getApiGroupSwagger` | `api_group` | `api_group`, `logic`, `frontend` |
| `deleteApiGroup` | `api_group` | `api_group`, `logic` |
| `createApiGroup` | `api_group` | `api_group`, `logic` |
| `updateApiGroup` | `api_group` | `api_group`, `logic` |
| `updateApiGroupSecurity` | `api_group` | `api_group`, `logic` |
| `listAddons` | `add_on` | `add_on`, `logic` |
| `getAddon` | `add_on` | `add_on`, `logic` |
| `deleteAddon` | `add_on` | `add_on`, `logic` |
| `createAddon` | `add_on` | `add_on`, `logic` |
| `updateAddon` | `add_on` | `add_on`, `logic` |
| `updateAddonSecurity` | `add_on` | `add_on`, `logic` |
| `listmiddlewares` | `middleware` | `middleware`, `logic` |
| `getMiddleware` | `middleware` | `middleware`, `logic` |
| `deleteMiddleware` | `middleware` | `middleware`, `logic` |
| `createMiddleware` | `middleware` | `middleware`, `logic` |
| `updateMiddleware` | `middleware` | `middleware`, `logic` |
| `updateMiddlewareSecurity` | `middleware` | `middleware`, `logic` |
| `listTasks` | `task` | `task`, `logic` |
| `getTask` | `task` | `task`, `logic` |
| `deleteTask` | `task` | `task`, `logic` |
| `createTask` | `task` | `task`, `logic` |
| `updateTask` | `task` | `task`, `logic` |
| `updateTaskSecurity` | `task` | `task`, `logic` |
| `listWorkspaceTriggers` | `workspace_trigger` | `workspace_trigger`, `logic` |
| `getWorkspaceTrigger` | `workspace_trigger` | `workspace_trigger`, `logic` |
| `deleteWorkspaceTrigger` | `workspace_trigger` | `workspace_trigger`, `logic` |
| `createWorkspaceTrigger` | `workspace_trigger` | `workspace_trigger`, `logic` |
| `updateWorkspaceTrigger` | `workspace_trigger` | `workspace_trigger`, `logic` |
| `updateWorkspaceTriggerSecurity` | `workspace_trigger` | `workspace_trigger`, `logic` |
| `listWorkflowTests` | `workflow_test` | `workflow_test`, `logic` |
| `getWorkflowTest` | `workflow_test` | `workflow_test`, `logic` |
| `deleteWorkflowTest` | `workflow_test` | `workflow_test`, `logic` |
| `createWorkflowTest` | `workflow_test` | `workflow_test`, `logic` |
| `updateWorkflowTest` | `workflow_test` | `workflow_test`, `logic` |
| `updateWorkflowTestSecurity` | `workflow_test` | `workflow_test`, `logic` |
| `listWorkspaceTableTriggers` | `table_trigger` | `table_trigger`, `logic` |
| `getTableTrigger` | `table_trigger` | `table_trigger`, `logic` |
| `deleteTableTrigger` | `table_trigger` | `table_trigger`, `logic` |
| `createTableTrigger` | `table_trigger` | `table_trigger`, `logic` |
| `updateTableTrigger` | `table_trigger` | `table_trigger`, `logic` |
| `updateTableTriggerSecurity` | `table_trigger` | `table_trigger`, `logic` |
| `listAPIs` | `api` | `api`, `logic` |
| `getAPI` | `api` | `api`, `logic` |
| `deleteAPI` | `api` | `api`, `logic` |
| `createAPI` | `api` | `api`, `logic` |
| `updateAPI` | `api` | `api`, `logic` |
| `updateAPISecurity` | `api` | `api`, `logic` |
| `getApiSwagger` | `api` | `api`, `logic`, `frontend` |
| Tool Name | Type | Tags |
| :--------------------------- | :---------------------- | :---------------------------------- |
| `getTables` | `table` | `table`, `database` |
| `getTable` | `table` | `table`, `database` |
| `addTable` | `table` | `table`, `database` |
| `updateTable` | `table` | `table`, `database` |
| `updateTableMeta` | `table` | `table`, `database` |
| `deleteTable` | `table` | `table`, `database` |
| `getTableContent` | `table_content` | `table_content`, `database` |
| `getTableContentItem` | `table_content` | `table_content`, `database` |
| `searchTableContent` | `table_content` | `table_content`, `database` |
| `deleteTableContentItem` | `table_content` | `table_content`, `database` |
| `addTableContent` | `table_content` | `table_content`, `database` |
| `addTableContentBulk` | `table_content` | `table_content`, `database` |
| `patchTableContentBulk` | `table_content` | `table_content`, `database` |
| `deleteTableContentBulk` | `table_content` | `table_content`, `database` |
| `deleteTableContentBySearch` | `table_content` | `table_content`, `database` |
| `patchTableContentBySearch` | `table_content` | `table_content`, `database` |
| `updateTableContentItem` | `table_content` | `table_content`, `database` |
| `truncateTable` | `table_content` | `table_content`, `database` |
| `listTableIndexes` | `table_index` | `table_index`, `database` |
| `createBtreeIndex` | `table_index` | `table_index`, `database` |
| `createSearchIndex` | `table_index` | `table_index`, `database` |
| `createUniqueIndex` | `table_index` | `table_index`, `database` |
| `createVectorIndex` | `table_index` | `table_index`, `database` |
| `createSpatialIndex` | `table_index` | `table_index`, `database` |
| `deleteTableIndex` | `table_index` | `table_index`, `database` |
| `replaceTableIndexes` | `table_index` | `table_index`, `database` |
| `getTableSchema` | `table_schema` | `table_schema`, `database` |
| `deleteTableSchemaElement` | `table_schema` | `table_schema`, `database` |
| `getTableSchemaElement` | `table_schema` | `table_schema`, `database` |
| `updateTableSchema` | `table_schema` | `table_schema`, `database` |
| `renameTableColumn` | `table_schema` | `table_schema`, `database` |
| `listFiles` | `files` | `files`, `database` |
| `uploadFile` | `files` | `files`, `database` |
| `deleteFiles` | `files` | `files`, `database` |
| `deleteFile` | `files` | `files`, `database` |
| `workspaceGetDataSources` | `workspace_datasources` | `workspace_datasources`, `database` |
| `createDataSource` | `workspace_datasources` | `workspace_datasources`, `database` |
| `updateDataSource` | `workspace_datasources` | `workspace_datasources`, `database` |
| `deleteDataSource` | `workspace_datasources` | `workspace_datasources`, `database` |
| `getWorkspaceOpenApi` | `workspace` | `workspace`, `openapi`, `frontend` |
| `generateWorkspaceSdk` | `workspace` | `workspace`, `sdk`, `frontend` |
| Tool Name | Type | Tags |
| :---------------------------- | :------------ | :------------------------ |
| `listStaticHosts` | `static_host` | `static_host`, `frontend` |
| `listStaticHostBuilds` | `static_host` | `static_host`, `frontend` |
| `createStaticHostBuild` | `static_host` | `static_host`, `frontend` |
| `updateStaticHostEnvironment` | `static_host` | `static_host`, `frontend` |
| Tool Name | Type | Tags |
| :------------------------------- | :------------------- | :---------------------------- |
| `getApiRequestHistory` | `request_history` | `request_history`, `audit` |
| `searchApiRequestHistory` | `request_history` | `request_history`, `audit` |
| `getWorkspaceAuditLogs` | `audit_logs` | `audit_logs`, `audit` |
| `getAuditLogs` | `audit_logs` | `audit_logs`, `audit` |
| `searchWorkspaceAuditLogs` | `audit_logs` | `audit_logs`, `audit` |
| `searchAuditLogs` | `audit_logs` | `audit_logs`, `audit` |
| `getFunctionRequestHistory` | `function_history` | `function_history`, `audit` |
| `searchFunctionRequestHistory` | `function_history` | `function_history`, `audit` |
| `getTaskRequestHistory` | `task_history` | `task_history`, `audit` |
| `searchTaskRequestHistory` | `task_history` | `task_history`, `audit` |
| `getTriggerRequestHistory` | `trigger_history` | `trigger_history`, `audit` |
| `searchTriggerRequestHistory` | `trigger_history` | `trigger_history`, `audit` |
| `getMiddlewareRequestHistory` | `middleware_history` | `middleware_history`, `audit` |
| `searchMiddlewareRequestHistory` | `middleware_history` | `middleware_history`, `audit` |
| `getToolRequestHistory` | `tool_history` | `tool_history`, `audit` |
| `searchToolRequestHistory` | `tool_history` | `tool_history`, `audit` |
# Xano MCP Tools
Source: https://docs.xano.com/building/build-with-ai/xano-mcp-tools
A list of all the tools available in the Xano MCP Server
The Xano MCP Tools are a collection of tools that you can use to build your entire backend with AI.
## Authentication
* `getLoggedInUser` — Identifies account details for the current Access Token.
* `documentation` — This utility provides a comprehensive overview of the MCP Server's operation and includes detailed documentation for the XanoScript syntax. To begin, use the type `"start"` to view all available commands.
## Addons
* `updateAddonSecurity` — Updates security settings for a workspace addon.
* `deleteAddon` — Deletes a workspace addon permanently.
* `getAddon` — Gets a specific addon by ID from a workspace.
* `updateAddon` — Updates a workspace addon using XanoScript.
* `listAddons` — Lists addons within a workspace.
* `createAddon` — Adds a new addon to a workspace using XanoScript.
## Agent Triggers
* `updateAgentTriggerSecurity` — Update agent trigger security configuration and access controls.
* `deleteAgentTrigger` — Delete an agent trigger permanently. This action cannot be undone.
* `getAgentTrigger` — Retrieve an agent trigger by ID.
* `updateAgentTrigger` — Update agent trigger using XanoScript.
* `listAgentTriggers` — Lists agent triggers.
* `createAgentTrigger` — Create a new agent trigger using XanoScript.
## Agents
* `deleteAgent` — Delete an agent permanently. This action cannot be undone.
* `getAgent` — Retrieve a specific agent by ID.
* `updateAgent` — Update agent details using XanoScript.
* `listAgents` — Lists agents within a workspace.
* `createAgent` — Create a new agent using XanoScript.
## APIs
* `getApiSwagger` — Returns the JSON output of the OpenAPI (Swagger) specification for a given API's REST endpoint.
* `updateAPISecurity` — Updates an API endpoint's security configuration and access controls.
* `deleteAPI` — Deletes an API endpoint permanently.
* `getAPI` — Retrieves a specific API endpoint by ID.
* `updateAPI` — Updates an API endpoint's code, settings, and authentication rules.
* `listAPIs` — Lists API endpoints within a specific API group.
* `createAPI` — Creates a new API endpoint using XanoScript.
## API Groups
* `getApiGroupSwagger` — Returns the JSON output of the OpenAPI (Swagger) specification for a given API group's REST endpoints.
* `updateApiGroupSecurity` — Updates security settings for an API group.
* `deleteApiGroup` — Deletes an API group and all its endpoints.
* `getApiGroup` — Retrieves details for a specific API group.
* `updateApiGroup` — Updates an existing API group.
* `listAPIGroups` — Lists API groups in a Xano workspace.
* `createApiGroup` — Creates a new API group in a workspace.
## Workspace Management
* `deleteWorkspaceBranch` — Deletes a branch within a workspace.
* `getWorkspaceBranches` — Lists branches within a workspace.
* `getWorkspaceContext` — Generates the full context for a workspace.
## Data Sources
* `deleteDataSource` — Deletes a data source permanently.
* `updateDataSource` — Updates an existing data source's label and color.
* `listDataSources` — Lists data sources within a workspace.
* `createDataSource` — Creates a new external data source.
## Files
* `deleteFiles` — Deletes multiple files permanently.
* `deleteFile` — Deletes a file permanently.
* `listFiles` — Retrieves workspace files with optional search, filtering, and pagination.
* `uploadFile` — Uploads a file to a workspace.
## Functions
* `updateFunctionSecurity` — Update function security configuration and access controls.
* `deleteFunction` — Delete a function permanently. This action cannot be undone.
* `getFunction` — Retrieve a specific function by ID.
* `updateFunction` — Update function code, metadata, and caching settings.
* `searchFunctionRequestHistory` — Searches API function request history within a specified Xano workspace. Allows for complex filtering (e.g., by status, verb) and sorting of function logs.
* `getFunctionRequestHistory` — Lists API function request history for a specified Xano workspace. Supports pagination and basic filtering by branch, API ID, or query ID.
* `listFunctions` — Lists functions within a workspace.
* `createFunction` — Create a new function using XanoScript.
## MCP Server Triggers
* `updateMCPServerTriggerSecurity` — Update mcp\_server trigger security configuration and access controls.
* `deleteMCPServerTrigger` — Delete a mcp\_server trigger permanently. This action cannot be undone.
* `getMCPServerTrigger` — Retrieve an mcp\_server trigger by ID.
* `updateMCPServerTrigger` — Update mcp\_server trigger using XanoScript.
* `listMcpServerTriggers` — Lists mcp\_server triggers.
* `createMCPServerTrigger` — Create a new mcp\_server trigger using XanoScript.
## MCP Server
* `deleteMCPServer` — Delete a MCP server permanently. This action cannot be undone.
* `getMCPServer` — Retrieve a specific MCP server by ID.
* `updateMCPServer` — Update MCP server details using XanoScript.
* `listMCPServers` — Lists MCP servers within a workspace.
* `createMCPServer` — Create a new MCP server using XanoScript.
## Middleware
* `updateMiddlewareSecurity` — Updates middleware security configuration and access controls.
* `deleteMiddleware` — Deletes a middleware permanently.
* `getMiddleware` — Retrieves a specific middleware by ID.
* `updateMiddleware` — Updates middleware code, metadata, and caching settings.
* `searchMiddlewareRequestHistory` — Searches middleware request history within a specified Xano workspace. Allows for complex filtering (e.g., by status, verb) and sorting of middleware logs.
* `getMiddlewareRequestHistory` — Lists middleware request history for a specified Xano workspace. Supports pagination and basic filtering by branch, API ID, or query ID.
* `listmiddlewares` — Lists middlewares within a workspace.
* `createMiddleware` — Creates a new middleware using XanoScript.
## Realtime
* `getWorkspaceOpenApi` — Returns the JSON output of the OpenAPI (Swagger) specification for all API groups in a workspace.
* `listRealtimeChannels` — Lists realtime channels.
* `listRealtimeTriggers` — Lists realtime triggers.
## API Request History
* `searchApiRequestHistory` — Searches API request history within a specified Xano workspace. Allows for complex filtering (e.g., by status, verb) and sorting of request logs.
* `getApiRequestHistory` — Lists API request history for a specified Xano workspace. Supports pagination and basic filtering by branch, API ID, or query ID.
* `generateWorkspaceSdk` — Generates a downloadable SDK package for all API groups in a workspace.
## Static Hosts
* `updateStaticHostEnvironment` — Updates a static hosting environment.
* `listStaticHostBuilds` — Retrieves builds for a static host.
* `createStaticHostBuild` — Creates a static host build.
* `listStaticHosts` — Retrieves workspace static hosts.
## Table Triggers
* `updateTableTriggerSecurity` — Updates security settings for a table trigger.
* `deleteTableTrigger` — Deletes a table trigger permanently.
* `getTableTrigger` — Retrieves a specific table trigger by ID.
* `updateTableTrigger` — Updates a table trigger using XanoScript.
* `listWorkspaceTableTriggers` — Lists workspace table triggers.
* `createTableTrigger` — Creates a new table trigger using XanoScript.
## Table Content
* `deleteTableContentBulk` — Deletes multiple records from a table in bulk.
* `patchTableContentBulk` — Updates multiple records in a table in bulk.
* `addTableContentBulk` — Adds multiple records to a table in bulk.
* `deleteTableContentBySearch` — Deletes table records matching search criteria.
* `patchTableContentBySearch` — Updates table records matching search criteria.
* `searchTableContent` — Searches records in a table.
* `deleteTableContentItem` — Deletes a specific record from a table.
* `getTableContentItem` — Retrieves a specific record from a table.
* `updateTableContentItem` — Updates a record in a table. The data for the fields you wish to update should be provided as additional key-value pairs directly within the arguments object. The keys should match the names of the columns in the table, and the values should be the new values for those columns.
* `getTableContent` — Retrieves records from a table.
* `addTableContent` — Adds a new record to a table. The data for the new record should be provided as additional key-value pairs directly within the arguments object. The keys should match the names of the columns in the table, and the values should be the values for those columns.
## Table Indexes
* `createBtreeIndex` — Creates a btree index on table columns to optimize query performance.
* `createSearchIndex` — Creates a full-text search index for table columns with language-specific optimization.
* `createSpatialIndex` — Creates a spatial index on a table for optimized geometry operations.
* `createUniqueIndex` — Creates a unique index on table fields to enforce data uniqueness and improve query performance.
* `createVectorIndex` — Creates a vector index on a table column with support for Inner Product, Cosine, L1, and L2 distance operations.
* `deleteTableIndex` — Deletes a specific table index.
* `listTableIndexes` — Retrieves all indexes for a database table.
* `replaceTableIndexes` — Replaces all indexes for a database table with a new configuration.
## Table Schema
* `updateTableMetadata` — Updates the metadata for a table.
* `renameTableColumn` — Renames a column in a table's schema.
* `deleteTableSchemaElement` — Deletes a column from a table's schema.
* `getTableSchemaElement` — Retrieves a specific column from a table's schema.
* `getTableSchema` — Retrieves the schema of a table.
* `updateTableSchema` — Replaces the entire schema of a table.
* `updateTableSecurity` — Updates security rules for a table using a GUID.
* `truncateTable` — Deletes all records from a table.
* `deleteTable` — Deletes a table and its data.
* `getTable` — Retrieves details for a specific table.
* `updateTable` — Updates a workspace table using XanoScript.
* `getTables` — Lists tables in a workspace.
* `addTable` — Creates a new database table in a workspace. Note: Xano automatically adds an `id` field (default primary key) and a `created_at` timestamp field; these do not need to be defined in the `schema` array.
## Tasks
* `updateTaskSecurity` — Updates scheduled task security configuration and access controls.
* `deleteTask` — Deletes a scheduled task permanently.
* `getTask` — Retrieves a specific scheduled task by ID.
* `updateTask` — Updates task code, schedule settings, and activation status.
* `searchTaskRequestHistory` — Searches task request history within a specified Xano workspace. Allows for complex filtering (e.g., by status, verb) and sorting of task logs.
* `getTaskRequestHistory` — Lists task request history for a specified Xano workspace. Supports pagination and basic filtering by branch, API ID, or query ID.
* `listTasks` — Lists tasks within a workspace.
* `createTask` — Creates a new scheduled task using XanoScript.
## Tools
* `updateToolSecurity` — Update tool security configuration and access controls.
* `deleteTool` — Delete a tool permanently. This action cannot be undone.
* `getTool` — Retrieve a specific tool by ID.
* `updateTool` — Update tool code, metadata, and caching settings.
* `searchToolRequestHistory` — Searches tool request history within a specified Xano workspace. Allows for complex filtering (e.g., by status, verb) and sorting of tool logs.
* `getToolRequestHistory` — Lists tool request history for a specified Xano workspace. Supports pagination and basic filtering by branch, API ID, or query ID.
* `listTools` — Lists tools within a workspace.
* `createTool` — Create a new tool using XanoScript.
## Workspace Triggers
* `updateWorkspaceTriggerSecurity` — Updates workspace trigger security configuration and access controls.
* `deleteWorkspaceTrigger` — Deletes a workspace trigger permanently.
* `getWorkspaceTrigger` — Retrieves a specific workspace trigger by ID.
* `updateWorkspaceTrigger` — Updates workspace trigger code, metadata, and caching settings.
* `searchTriggerRequestHistory` — Searches trigger request history within a specified Xano workspace. Allows for complex filtering (e.g., by status, verb) and sorting of trigger logs.
* `getTriggerRequestHistory` — Lists trigger request history for a specified Xano workspace. Supports pagination and basic filtering by branch, API ID, or query ID.
* `listWorkspaceTriggers` — Lists workspace triggers.
* `createWorkspaceTrigger` — Creates a new workspace trigger using XanoScript.
## Workflow Tests
* `updateWorkflowTestSecurity` — Updates security settings for a workspace workflow test.
* `deleteWorkflowTest` — Deletes a workspace workflow test permanently.
* `getWorkflowTest` — Gets a specific workflow test by ID from a workspace.
* `updateWorkflowTest` — Updates a workspace workflow test using XanoScript.
* `listWorkflowTests` — Lists workflow tests within a workspace.
* `createWorkflowTest` — Adds a new workflow test to a workspace using XanoScript.
## Workspaces
* `getWorkspace` — Retrieves details for a specific workspace.
* `listWorkspaces` — Lists workspaces accessible by the authenticated user.
# Building with Code
Source: https://docs.xano.com/building/code
Learn how to build with code in Xano
With XanoScript able to represent everything you can build in Xano, you can utilize the power and speed of having Xano power your backend without leaving where you're most comfortable -- your favorite IDE.
Coding with XanoScript can happen a couple of different ways:
You can write XanoScript in Xano directly in the XanoScript view. This is a great way to get started with XanoScript and see how it works, especially if you've already used the visual builder.
This option will be available when creating most logic in Xano, such as APIs, Custom Functions, Background Tasks, and more.
In some areas, such as AI Agents that open with a settings panel immediately, you'll see a XanoScript option at the top of the panel.
You can also use the VS Code extension to write XanoScript in an IDE of your choice. You should be able to use any IDE that supports VS Code extensions, such as Cursor or Windsurf, as well as VS Code itself.
**Get the VS Code extension from the Marketplace [here](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript)**
**Download directly from [here](https://storage.googleapis.com/xanoscript-vscode/vsix/xano.xanoscript-0.1.0.vsix)**
Using the Xano MCP server, you're able to connect an AI model to your Xano backend via an MCP client, like Claude or Cursor. The MCP server offers a number of tools to help you build your backend with AI.
All of these methods are powered by XanoScript, so you can use them interchangeably. If you want a deeper dive into XanoScript, you can learn more about it [here](/xanoscript/introduction).
**Switching between build modes?** Changes made in one build mode aren't automatically synced to another. For example, if you make changes in the visual builder and then want to continue working in the CLI, you'll need to [pull](/xano-cli/push-pull#pull) your workspace first to get the latest changes. The same applies when switching from any other mode back to the CLI.
# Addons in Xano
Source: https://docs.xano.com/building/logic/addons
Learn how to build and use Addons in Xano to fetch related data for APIs and other queries.
Before continuing, make sure you're familiar with:
* [Core Components](/building/logic/core-components)
* [Working with Data](/building/logic/working-with-data)
## Addons in Xano
Addons are reusable queries that allow you to fetch related or nested data alongside your main API responses. They are commonly used to join or expand data from related tables, such as fetching all tasks that belong to a specific user.
Each Addon has:
* A name (unique identifier, e.g., `tasks_of_lists`)
* Inputs (parameters to filter or join data)
* Logic (the query to fetch the related data)
Unlike APIs, Addons do not have a response block. The output of the query in the stack is returned by default.
## Creating an Addon
From a database operation function, click the Add Addon button in the Output tab. Addons can be nested under arrays, so make sure to select the correct location.
Choose Create a New Addon in the modal that appears.
Choose the table you'd like to get data from.
Choose whether the addon should return a single item (such as retrieving a user's location) or a list of items (such as retrieving all tasks that belong to a user). You can also return a count, a true/false value if the data exists, or an advanced aggregation.
In this example, we're getting a record from the `user` table, and retrieving all of the lists from the `lists` table that belong to that user. Select the field from table you're getting data from in the addon that relates back to the original table you're querying. So, on our `lists` table, we have a `user_id`, which is the ID of the user from the `user` table.
Click Next, give your addon a name, and click Save.
You'll then be able to select where the addon gets the value to look up in the related table; in this case, the `id` of the user record. Xano will fill this in by default for you, but you can change it here if necessary. You can also choose a key for the data to live under in the response.
Click Done to finalize your choices and create the addon.
A basic addon in XanoScript has two parts — **inputs** and **logic** (the query):
```javascript lines icon="code" Example of a basic addon in XanoScript theme={null}
addon tasks_of_lists {
input {
int lists_id? {
table = "lists"
}
}
stack {
db.query tasks {
where = $db.tasks.lists_id == $input.lists_id
return = {type: "list"}
}
}
}
```
For more information on how to build Addons in XanoScript, see the XanoScript Addon documentation.
# Building APIs in Xano
Source: https://docs.xano.com/building/logic/apis
Learn how to build APIs with no code, with code, or with AI, all in Xano
Before continuing, make sure you're familiar with:
* [Core Components](/building/logic/core-components)
* [Working with Data](/building/logic/working-with-data)
If you need a primer on what an API is, we've added a quick summary below. For more detailed information, check out [What is an API](/before-you-begin/key-concepts#-api) in the Before You Begin section.
## Building APIs in Xano
APIs are a core part of any backend. They allow you to connect your backend to other services and applications.
Each API is assigned a name, a verb, and a URL.
* The name is the unique identifier for the API. For example, `user_list`. We'll be referencing this sample API throughout the rest of this page.
* The verb is the HTTP verb that will be used to make the request. For example, `GET`.
* The URL is the endpoint that the API will be accessed at. For example, `https://myapi.com/user_list`.
APIs in Xano are built in three parts:
* Inputs
\-- Inputs are the data that the API will accept. For example, `name` and `email`.
* Logic
\-- The logic is the logic that will be executed when the API is called. For example, retrieving a record from your database or calculating a user's age.
* Response
\-- The response is the data that the API will return. For our `user_list` API, it might return a list of users, or a single user.
## API Groups
APIs live inside of API groups. Think of groups as folders that you can use to organize all of your different APIs. For example, you might have a group for your authentication APIs, a group for your user APIs, and a group for file storage APIs.
### Creating a new API Group
From the sidebar, click API, and then click **+ Add API Group**.
In the panel that opens, give your API group a name. You can also provide a description, tags for organization, and choose whether or not to make auto-generated API documentation available for this group.
| Parameter | Description |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| name | The name of the API group. This comes immediately after the `api_group` definition, and before the opening curly brace. |
| description | A description of the API group. |
| tags | Tags for organization. |
| Swagger (OpenAPI) Documentation | Options for auto-generated API documentation. By default, it will be public, non-tokenized documentation. You can switch to tokenized documentation by clicking the toggle and choosing "Private (requires token)", or disable it by clicking the toggle and selecting "Disabled". |
You can also create an API group using XanoScript.
```javascript theme={null}
api_group my_new_API_group {
description = "This is an awesome API group with awesome APIs"
tags = ["awesome"]
canonical = "awesome"
history = {inherit: true}
}
```
| Parameter | Description |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| name | The name of the API group. This comes immediately after the `api_group` definition, and before the opening curly brace. |
| description | A description of the API group. |
| canonical | The canonical ID of the API group. |
| swagger | Options for auto-generated API documentation. If not provided, it will default to public, non-tokenized documentation.
Use `swagger = {token: ""}` to create tokenized documentation.
Use ` swagger = {active: false}` to disable auto-generated API documentation. |
| tags | Tags for organization. |
| history | The request history settings for the API group. Defaults to `{inherit: true}`, which means it will inherit the request history settings from the workspace. |
The canonical ID is used to generate the endpoint URLs for the APIs in this group. If not provided, Xano will auto-generate one for you.
For example, if the canonical ID is set to `awesome`, the base URL for the APIs in this group will be `https://yourdomain.com/api:awesome/api_name`.
## Creating a new API
Clicking the **+ Add API Endpoint** button will open a panel that allows you to create a new API.
You can choose from one of the following options:
| Type | Description |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Custom Endpoint** | Creates a blank canvas for you to build your API from scratch. |
| **External API request** | Creates a pre-built API for making requests to external APIs. |
| **CRUD Database Operations** | Creates a pre-built API for performing CRUD operations (Create, Read, Update, Delete) on a database table. |
| **Webhook** | Creates a pre-built API for receiving webhooks from external services. |
| **Authentication** | Creates a pre-built API for authentication. |
| **Upload Content** | Creates a pre-built API for uploading files, such as images or attachments. |
| **HTML Page** | Creates a pre-built API for serving HTML pages. |
| **Use XanoScript** | Opens the XanoScript editor so you can build your API from scratch. |
You'll be asked to provide some basic information about your API before continuing.
| Parameter | Description |
| -------------- | ----------------------------------------------------------------------------------------------------- |
| Name | The name of the API. |
| Verb | The HTTP verb that will be used to make the request. |
| Description | A description of the API. |
| Tags | Tags for organization. |
| Authentication | Choose whether this endpoint requires a valid authentication token present in the headers to execute. |
You can build APIs in Xano in three different ways. Choose the one that best fits your needs. You can switch between them at any time.
## The Canvas View
The canvas view is a visual representation of your API in a node-based format. If you're new to the canvas view, review the [Canvas View](/building/build-visually/canvas-view) basics first.
Inputs define the data your API expects. Learn how to add and configure them.
Functions define the behavior of your API. Add and arrange functions to process inputs and fetch data.
Control exactly what data your API sends back.
Inputs define the data your API expects. Learn how to add and configure them.
Functions define the behavior of your API. Add and arrange functions to process inputs and fetch data.
Control exactly what data your API sends back.
A basic API in XanoScript has three parts — **inputs**, **functions**, and **response** — just like in the visual builder:
```javascript lines icon="code" Example of a basic API in XanoScript theme={null}
query user_list verb=GET {
description = "Query all user records"
input {
text name? filters=trim
}
stack {
db.query user {
search = $db.user.name ==? $input.name
return = {type: "list"}
} as $model
}
response {
value = $model
}
history = {inherit: true}
}
```
For more information on how to build APIs in XanoScript, see the XanoScript API documentation.
# Background Tasks in Xano
Source: https://docs.xano.com/building/logic/background-tasks
Learn how to build and schedule background tasks (cron jobs) in Xano using the visual builder or XanoScript.
Before continuing, make sure you're familiar with:
* [Core Components](/building/logic/core-components)
* [Working with Data](/building/logic/working-with-data)
## Background Tasks in Xano
Background tasks (also called scheduled tasks or cron jobs) allow you to automate operations at specific times or intervals. They are ideal for recurring jobs like data cleanup, report generation, or sending notifications.
Each background task has:
* A name (unique identifier, e.g., `daily_sales_report`)
* Logic (the actions to perform)
* A schedule (when and how often to run)
Unlike APIs, background tasks **do not** have inputs or responses. They only contain logic and a schedule block.
## Creating a Background Task
You can create background tasks visually or with XanoScript.
### Visual Builder
From the sidebar, click Tasks, then click Add Background Task. You can also just hover over Tasks and click the + icon.
Give your task a name and description, and choose the data source that the task will run against, by default. If you don't choose a data source, scheduled runs will always use the live data source.
Add functions to your task by clicking Add Function. You can use any function available in Xano, just like in APIs.
When you've finished building your logic, you can set up the schedule by clicking the Add a schedule option.
Schedules have a start date / time, and can run once or on a repeating interval (e.g., every hour, day, week, etc.). For tasks that have a repeating schedule, you can also set an end date.
After configuring the schedule, click Save to create your background task.
You'll need to enable your task before publishing by selecting the option.
Once you've set your schedule and enabled the task, click Publish to deploy your background task.
### XanoScript
A basic background task in XanoScript has two parts — **logic** and **schedule**:
```javascript lines icon="code" Example of a basic background task in XanoScript theme={null}
// This task runs every day at 11 PM UTC and generates a sales report
task daily_sales_report {
description = "Generate a daily sales report at 11 PM UTC"
stack {
db.query payment_transactions {
description = "Get all transactions from the past 24 hours"
where = $db.payment_transactions.transaction_date >= (now|transform_timestamp:"24 hours ago":"UTC")
} as $daily_sales
var $transaction_count {
value = $daily_sales|count
description = "Count number of transactions"
}
var $total_sales {
value = ($daily_sales[$$].amount)|sum
description = "Calculate total sales amount"
}
db.add reports {
data = {
report_type : "daily_sales"
report_date : now
total_sales : $total_sales
transaction_count: $transaction_count
}
description = "Insert daily sales report"
} as $report_result
debug.log {
value = "Daily sales report generated"
description = "Log report generation"
}
}
schedule = [{starts_on: 2025-10-20 13:47:35+0000, freq: 86400}]
}
```
For more information on how to build background tasks in XanoScript, see the XanoScript Task documentation.
# Core Components of Logic
Source: https://docs.xano.com/building/logic/core-components
Learn about what makes up the logic and workflows you build in Xano
## Logic Basics
Logic that you build in Xano is made up of several core components that you'll see across the entire platform. Each primitive, or 'thing you can build' (like APIs, AI Agents, and more) has its own set of components it uses, but you'll also find some overlap between them. For example, APIs, custom functions, and AI tools all use inputs, but background tasks don't. However, those same primitives all have a stack which contains what will actually run when it's time to do so.
Inputs are the data that the logic might need to perform its operation. They are declared in the input block of the primitives that support them. Inputs are optional, but the block must be declared even if empty.
What happens during execution. Your logic can be comprised of any combination of:
**Functions**
* Functions are individual pieces of logic, like getting a record from the database, or generating a random number.
**Filters**
* Filters are applied 'inline' to other values, and are used to transform or manipulate data, such as trimming whitespace or converting to uppercase.
The response is what the logic will return when it's executed. It can be a value, a message, a JSON object; almost anything you want. Responses can be returned from a variable, or manually defined in the response itself.
Variables are used to store data that can be reused throughout your logic. They are declared in the variable block of the primitives that support them. Variables are optional, but the block must be declared even if empty.
Environment variables are persistent variables that are available across your entire workspace. Typically, these are used to store things like external API keys that you need to use across multiple function stacks.
# Environment Variables
Source: https://docs.xano.com/building/logic/core-components/environment-variables
# Environment Variables
> Variables that are available across your entire workspace
## What are environment variables?
Environment variables are persistent variables that are available across your entire workspace. Typically, these are used to store things like external API keys or other sensitive information that you need to use across multiple function stacks, without storing it in a database table.
Environment variables can be read in any logic or workflow, but they can not be modified from anywhere but this settings panel, so it's best to only use them for things that you don't need to change often.
## Adding Environment Variables
Click the icon in the upper-right corner to open **Settings**.
On the next screen, click 'Manage' to edit your environment variables.
Click '+ Add Variable' at the bottom of the panel that opens to add a new variable.
Give your environment variable a name that you can easily recognize; this is how you'll identify it when calling it in function stacks. Then, supply the value.
## Using Environment Variables
Environment variables are available in any logic or workflow from a value dropdown under **ENV**.
## Xano-generated Environment Variables
Xano maintains several environment variables you can use.
| Variable | Description |
| ---------------------- | ---------------------------------------------------------------------------- |
| `$remote_ip` | Resolves to the IP address of the individual accessing the API endpoint. |
| `$http_headers` | A text array of headers that are sent to the API endpoint. |
| `$api_baseurl` | Contains the base URL of the active endpoint. |
| `$request_uri` | Contains the URI being accessed from the API. |
| `$request_method` | The HTTP method (`GET`, `POST`, `DELETE`, etc.) of the incoming API request. |
| `$request_querystring` | Contains the query string of the URI being accessed from the API. |
| `$request_auth_token` | Contains the authorization token of the API request. |
| `$datasource` | Indicates which datasource is being used. |
| `$branch` | Indicates which branch is being used. |
***
> To find navigation and other pages in this documentation, fetch the llms.txt file at: [https://docs.xano.com/llms.txt](https://docs.xano.com/llms.txt)
# Filters
Source: https://docs.xano.com/building/logic/core-components/filters
Use filters to manipulate data throughout your logic
Filters are used to manipulate data throughout your logic. They can be applied almost anywhere that data is generated or referenced; anything from creating a variable to manipulating the response object on the fly.
## Adding Filters
Hover over a value box and click **Add Filter.**
You can search for filters using the search bar, navigate using the categories, or scroll through the list.
Filters will have various options available depending on the filter chosen, so it's best to consult that filter's specific documentation for more information.
Hover over an existing filter to see some additional actions.
| | Action |
| ----------------------------------------- | ------------------------------------------------------------------------- |
| | Click and drag to reorder filters. |
| | Click to disable the filter. Upon execution, this filter will be skipped. |
| | Click to clone the filter. |
| | Click to delete the filter. |
You can nest filters by adding them to an existing filter's value box(es).
Filters are defined immediately after the target value using the `|` pipe character.
```javascript lines icon="code" Filter syntax format theme={null}
|::
```
You can also nest filters by adding them to an existing filter's values in parantheses.
```javascript lines icon="code" Nested filter syntax format theme={null}
|(::)|
```
## Filter Reference
Review all available filters below by selecting the section you're interested in.
Transform or traverse data using conditional or object-based filters.
Perform arithmetic operations.
Convert or adjust timestamps.
Trim, format, or modify text.
Add, remove, or manipulate array items.
Convert data between types or formats.
Compare values for equality or other conditions.
Encrypt, validate, or secure data.
# Functions
Source: https://docs.xano.com/building/logic/core-components/functions
The functions that make up your logic
Functions are the building blocks of logic. They can be used to perform actions, such as retrieving a record from the database, or generating a random number.
## Adding a Function
Hover over a node and click the plus icon to insert a new function after it. You can also hover over the connecting lines to insert a function at that point in the flow.
In the panel that opens on the right, you can select the function you want to add. Use the search at the top, or navigate through the function categories.
Each function will have a different set of options available to you, so it's best to consult that function's specific documentation for more information.
Add a function by clicking the **+ Add Function** button below the function stack, hover over a function and click the **+** sign, or use your up and down arrow keys to select a row, and press A on your keyboard to add a new function.
In the panel that opens on the right, you can select the function you want to add. Use the search at the top, or navigate through the function categories.
Each function will have a different set of options available to you, so it's best to consult that function's specific documentation for more information.
After you add a function, Xano will sometimes suggest the most likely next step; for example, adding a Query All Records will suggest a loop after. You can choose to add the suggestion, ignore it, or just continue working and Xano will dismiss the suggestion automatically.
Functions are defined in the `stack` block, placed immediately after the declaration and accompanying parameters, such as the description.
```javascript lines icon="code" Example of the stack block and positioning theme={null}
stack {
db.query user {
search = $db.user.name ==? $input.name
return = {type: "list"}
} as $model
}
```
Functions begin with a **namespace** — basically, a category that the function is a part of. Each namespace is followed by a period, with the function name immediately after. After that, you'll declare any parameters the function requires. Functions can also have a description, which is optional.
```javascript lines icon="code" Stack with function declaration theme={null}
stack {
function_namespace.function_name {
description = ""
=
}
}
```
## Function Reference
Review all available functions below by selecting the section you're interested in.
Database Requests are used perform operations against your database tables,
such as retrieving, creating, updating, and deleting records.
Data Manipulation is used to parse and manipulate data, such as looping,
filtering, sorting, and transforming data.
Security is used to secure your data, such as encrypting data, and validating
data.
APIs and Lambdas are used to create APIs and lambdas, such as creating APIs
and lambdas.
Functions for using AI and related tools, such as Agents, the Template Engine,
and MCP Servers.
Data Caching (Redis) is used to cache data, such as caching data in Redis.
Actions are reusable building blocks by the Xano team and community that you
can use in your own workspace.
Custom Functions contain all of the custom functions you've created.
Utility Functions are used for things like debugging, error handling,
grouping, and more.
File Storage functions are used to store, retrieve, and manage files in your
Xano files library.
Cloud Services are used to connect to cloud services, such as Algolia, AWS
OpenSearch, S3, and more.
# Inputs
Source: https://docs.xano.com/building/logic/core-components/inputs
Data that is supplied to the logic before execution
Inputs are the data that is supplied to the primitive *outside of Xano* that it needs to run. For example, an API used to log in would probably need an email and a password.
There are several different types of inputs you can use to handle any data type. You can also make inputs optional, required, lists, or apply filters to transform them or require them to meet certain criteria.
### Adding an Input
Inputs are defined in the `input` block, placed immediately after the declaration and accompanying parameters, such as the description.
```javascript lines icon="code" Example of the input block and positioning theme={null}
query user_list verb=GET {
description = "Query all user records"
input {
text name? filters=trim
}
...
}
```
Each input will have a different set of options depending on the input type chosen. Keep reading to see more information about all of the available input types and available options.
### Input Options
| Option | Explanation | Example |
| ------------------------ | --------------------------------------------- | ---------------------------------------------------------- |
| Description | A short, human-readable summary of the input. | For an `email` field: “The user’s email address.” |
| Data structure | Single value or list of values. | Set to `list` to allow multiple values. |
| Allow nullable values | Whether the input can be `null`. | Set to `true` to allow `null`. |
| Default value | Value used if input isn’t provided. | Useful for optional fields that still need a stored value. |
| Required | Whether the input must be provided. | Set to `true` to make the field mandatory. |
| Sensitive data | Whether the field contains sensitive info. | Set to `true` to hide it from request history. |
| Custom rules and filters | Filters and validation applied to the input. | e.g. `trim` to remove whitespace. |
## Filters and Rules
With your input selected, scroll down to the Custom Rules and Filters section, and choose **+ Add an Input Rule**.
Filters and rules are defined in the input block, placed immediately after the input type.
```javascript lines icon="code" Example of filters and rules in XanoScript theme={null}
text name? filters=trim|lower
text name? min:8|minAlpha:1|minDigit:1
```
### Input Filters
Transform the data sent to the input on the fly.
| Filter | Explanation | Example |
| ------- | -------------------------------- | -------------------------------------------------------------------------------------------------------- |
| `trim` | Trims whitespace from the input. | ` hello ` becomes `hello`
|
| `lower` | Converts the input to lowercase. | `HELLO` becomes `hello`
|
| `upper` | Converts the input to uppercase. | `hello` becomes `HELLO`
|
### Input Rules
Validate the data sent to the input. If the data doesn't meet the criteria, the logic will fail to execute.
| Rule | Explanation | Example |
| ------------ | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `min` | Requires a minimum length. | `Hello` is not valid, but `Hello World` is.
|
| `max` | Requires a maximum length. | `Hello World` is not valid, but `Hello` is.
|
| `startsWith` | Requires a prefix. | If set to `invoice-`, `invoice-abc123` is valid, but `abc123` is not.
|
| `prevent` | Prevents a phrase. | If set to `hello`, `hello world` is not valid, but `goodbye world` is.
|
| `alphaOk` | Allows alphabetic characters only. | `hello` is valid, but `hello123` is not.
|
| `digitOk` | Allows numerical characters only. | `hello` is not valid, but `123` is.
|
| `ok` | Allows only specific characters. | If set to `abc123`, `hello` is not valid, but `abc123` is. `abc` is valid, but `cde` is not.
|
## Input Reference
Review all available input types below by selecting the section you're interested in.
A plain string of text, code, or any other characters.
A whole number, such as a count, year, or ID.
A Universally Unique Identifier — a random string used to ensure record uniqueness.
A JSON object with a defined schema (e.g., user settings or product details).\\
```json lines icon="code" Example of an object input theme={null}
{
"name": "John Doe",
"age": 30,
"email": "john.doe@example.com"
}
```
An integer or UUID referencing a record in another table.
A fixed-length array of numbers (embedding) for similarity search in AI/ML.
A predefined list of values to enforce consistency (e.g., "To Do", "In Progress", "Done", "Pending").
A point in time in milliseconds since the Unix Epoch (Jan 1, 1970).
A calendar date in YYYY-MM-DD format.
A true or false value.
A number with a decimal point (e.g., 1.5, 100.00, 0.001).
An email address.
A hashed and salted password. Plain text is never stored or retrievable.
A flexible JSON object or array without a defined schema — ideal for variable data (e.g., from external APIs).
```json lines icon="code" Example of a JSON input theme={null}
{
"name": "John Doe",
"age": 30,
"email": "john.doe@example.com"
}
```
File metadata for images, videos, audio, or other files (e.g., URL, name, size, type). Actual files are not stored in the database.
Stores geographic data such as a point, path, or polygon.
# Logic
Source: https://docs.xano.com/building/logic/core-components/logic
The business logic that executes when called
The logic is where all of the actual steps that execute when called live; what happens when it's executed. Your logic can be comprised of any combination of:
**Functions**
* Functions are individual pieces of logic, like getting a record from the database, or generating a random number.
To review all of the available functions, see the [Functions Reference](/the-function-stack/functions).
**Filters**
* Filters are applied 'inline' to other values, and are used to transform or manipulate data, such as trimming whitespace or converting to uppercase.
To review all of the available filters, see the [Filters Reference](/the-function-stack/filters).
# Response
Source: https://docs.xano.com/building/logic/core-components/response
Anything that is returned when the logic is complete
The response is what the logic will return when it's executed. It can be a value, a message, a JSON object; almost anything you want. Responses can be returned from a variable, or manually defined in the response itself.
Not all primitives support responses; see below.
| Primitive | Supports Response | Notes |
| --------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------- |
| API | Yes | Returns the JSON object defined in the response block |
| AI Agent | No | Your agent will return messages to the user, but you don't directly define the response like other primitives |
| Trigger | Yes | Returns the JSON object defined in the response block |
| Background Task | No | No responses are supported |
| Custom Function | Yes | Returns the JSON object defined in the response block |
| Middleware | Yes | Returns the JSON object defined in the response block |
| AI Tool | Yes | Returns the JSON object defined in the response block |
| MCP Server | No | Your tools will deliver messages back to the MCP client, but you don't directly define a response like other primitives |
## Adding a Response
Responses will usually come from a variable of some kind, but you can also manually define a static value, or use filters to create a combination of both.
When building visually, Xano will automatically add a response of the first variable in the stack. For example, if you start by adding a Query All Records function, Xano will make sure that the response is the output of that function.
Responses can be returned as `self`, meaning that it is not nested in another object.
```json lines icon="code" Example of a self response theme={null}
{
"id": 1,
"created_at": 1760368044972,
"name": "Erin Porter",
"email": "mei.payne@google.com"
}
```
You can also return each response as its own nested object.
```json lines icon="code" Example of a nested response theme={null}
{
"user": {
"id": 1,
"created_at": 1760368044972,
"name": "Erin Porter",
"email": "mei.payne@google.com"
}
}
```
Find your response block and choose **Add a Response**.
Give your response a name, and choose whether you want to return it as `self` or nested under another value.
Find your response block and choose **Add a Response**.
Give your response a name, and choose whether you want to return it as `self` or nested under another value.
The response block is placed towards the end of the primitive, after the logic and before any additional settings.
```javascript lines icon="code" Example of a response in XanoScript theme={null}
response {
value = {user: $model}
}
```
To return a self response, forgo the object and keep only the `value` assignment.
```javascript lines icon="code" Example of a self response in XanoScript theme={null}
response {
value = $model
}
```
# Building Custom Functions in Xano
Source: https://docs.xano.com/building/logic/custom-functions
Learn how to build Custom Functions (reusable logic)
Before continuing, make sure you're familiar with:
* [Core Components](/building/logic/core-components)
* [Working with Data](/building/logic/working-with-data)
## Building Custom Functions in Xano
Custom Functions are a way to build reusable logic that you can utilize in other workflows. They allow you to build a set of steps once, use them in multiple places, and maintain them in one place.
Custom Functions in Xano are built in three parts:
* Inputs
\-- Inputs are the data that the Custom Function will accept. For example, `name` and `email`.
* Logic
\-- The logic is the logic that will be executed when the Custom Function is called. For example, retrieving a record from your database or calculating a user's age.
* Response
\-- The response is the data that the Custom Function will return. For our `user_list` Custom Function, it might return a list of users, or a single user.
## Custom Function Folders
You can organize your Custom Functions into folders for better organization by adding a folder name to the Custom Function name -- for example, `utilities/user_list` instead of just `user_list`.
You can select Move functions to move your Custom Functions into a folder, and Add Folder to add a new folder.
## Creating a new Custom Function
From the sidebar, click Functions or hover over it and click to create a new function immediately.
Clicking the **+ Add Function** button will open a panel that allows you to create a new Custom Function.
You'll be asked to provide some basic information about your Custom Function before continuing.
| Parameter | Description |
| --------------- | ----------------------------------------------------------------------------------------------------------- |
| Name | The name of the Custom Function. |
| Description | A description of the Custom Function. |
| Folder Path | The folder path for the Custom Function; this is optional and you don't need to use a folder if you prefer. |
| Tags | Tags for organization. |
| Request History | The request history settings for the Custom Function. |
You can build Custom Functions in Xano in three different ways. Choose the one that best fits your needs. You can switch between them at any time.
## The Canvas View
The canvas view is a visual representation of your custom function in a node-based format. If you're new to the canvas view, review the [Canvas View](/building/build-visually/canvas-view) basics first.
Inputs define the data your custom function expects. Learn how to add and configure them.
Functions define the behavior of your custom function. Add and arrange functions to process inputs and fetch data.
Control exactly what data your custom function sends back.
Inputs define the data your custom function expects. Learn how to add and configure them.
Functions define the behavior of your API. Add and arrange functions to process inputs and fetch data.
Control exactly what data your API sends back.
A basic custom function in XanoScript has three parts — **inputs**, **functions**, and **response** — just like in the visual builder:
```javascript lines icon="code" Example of a basic custom function in XanoScript theme={null}
function utilities/format_timestamp {
description = "Makes a timestamp human readable"
input {
timestamp? timestamp?
}
stack {
var $readable_timestamp {
value = $input.timestamp|format_timestamp:"r":"UTC"
}
}
response {
value = $readable_timestamp
}
middleware = {pre: [], post: []}
}
```
For more information on how to build custom functions in XanoScript, see the XanoScript custom functions documentation.
# Logic & Workflows
Source: https://docs.xano.com/building/logic/logic
Everything you can build with Xano's logic engine — APIs, functions, tasks, triggers, and middleware.
Xano's logic engine is where your backend comes to life. Build workflows that handle requests, run on schedules, react to events, and more — visually, with code, or with AI.
Build HTTP endpoints that power your apps. Define inputs, add logic, query data, and return responses — all from one place.
Create reusable blocks of logic that can be called from APIs, tasks, triggers, or other functions.
Schedule logic to run on a timer (cron jobs) or execute long-running processes in the background.
Run workflows automatically in response to events — database changes, realtime messages, agent actions, and more.
Add logic that executes before or after other workflows — useful for auth checks, logging, and request validation.
Fetch related data alongside your queries — join tables, aggregate results, and enrich responses without extra requests.
***
## Building blocks
These are the shared components and concepts used across all logic types.
Inputs, logic statements, functions, filters, and responses — the pieces every workflow is made of.
Variables, environment variables, and dot notation — how you store, access, and transform data inside logic.
# Middleware
Source: https://docs.xano.com/building/logic/middleware
Middleware is used to add additional logic that executes before or after other logic.
Before continuing, make sure you're familiar with:
* [Core Components](/building/logic/core-components)
* [Working with Data](/building/logic/working-with-data)
You'll also want to make sure you've already built something to apply middleware to.
Middleware enables additional control of your logic at pivotal points of execution. They are separate pieces of logic that can run before the logic executes (before input validation) or after the logic executes (after the response is generated, but before it is delivered).
Middleware can be applied to:
* APIs
* Custom Functions
* Background Tasks
* AI Tools
Middleware is available on any paid plan. You may be limited on the amount of middleware you can create depending on your plan; if you have questions, check your [billing screen](https://app.xano.com/billing) or contact our support team.
There are two types of middleware:
* **Pre-middleware** that runs before input validation
* **Post-middleware** that runs after the logic executes and a response is generated, but before it is delivered
You'll need to understand response and exception types when building your middleware.
Response types are used to determine how the middleware handles generating a response once it's done executing.
| Response Type | Description |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `merge` | Merges the response of the middleware with the existing response. If the middleware response contains a key that already exists in the generated response, it will be overwritten. |
| `replace` | Replaces the existing response entirely with the new response |
Exception methods are used to determine how the middleware handles errors that occur during execution.
| Exception Method | Description |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `critical` | Stops execution completely and returns an error |
| `silent` | Silently ignores errors |
| `rethrow` | When paired with post-middleware, it allows the post-middleware to run even when an error occurs in the pre-middleware. Good for error logging or monitoring. |
Middleware has predefined inputs that can not be changed. These inputs are:
* `vars` - The variables from the parent object. This could be either the inputs sent to the workflow for a pre-middleware, or the response generated by the parent object for a post-middleware.
* `type` - The type of middleware (pre or post).
## Building Middleware in Xano
From the sidebar, click Middleware.
Click the Add Middleware button in the top-right corner.
Give your middleware a name, description, and any tags you'd like to apply. Choose your response type and exception method.
A basic middleware in XanoScript has three parts — **inputs**, **functions**, and **response** — just like in the visual builder:
```javascript lines icon="code" Example of a basic middleware in XanoScript theme={null}
middleware check_banned_user {
description = "Checks to see if a banned user is attempting to perform any action, and if so, blocks it"
input {
json vars
enum type {
values = ["pre", "post"]
}
}
stack {
db.get user {
field_name = "id"
field_value = $auth.id
} as $user1
precondition ($user1.banned == false) {
error_type = "unauthorized"
error = "Your account has been suspended."
}
}
response {
value = {user1: $user1}
}
response_strategy = "merge"
exception_policy = "critical"
tags = ["user actions"]
```
For more information on how to build middleware in XanoScript, see the XanoScript Middleware documentation.
Once you've build your middleware, you'll need to apply it to the workflows you want it to run with.
## Applying Middleware to Workflows
Middleware can be applied at the workspace level, workflow group level (like API groups), or onto individual workflows. If no customizations are set on a workflow, it will inherit middleware settings from their parent object, such as the group they reside in or the workspace.
You can quickly disable middleware by clicking the toggle and remove it completely from the object by clicking the .
### Workspace level
Click Middleware in the left-hand navigation. On the middleware screen, click Manage Global Defaults.
Alternatively, you can click the in the top right anywhere in Xano and choose Middleware Defaults from the modal that opens.
Middleware Defaults will only be available once you have at least one middleware built. Until then, you'll simply be redirected to the Middleware section.
Select the workflow type you want to apply your middleware to. You can choose from:
* APIs
* AI Tools
* Functions
* Tasks
Click Add on either PRE or POST middleware to apply one of your created middleware to that section.
### Applying middleware to a workflow group
Group level middleware only applies to APIs.
From an API group, click and select Middleware.
### Applying middleware to an individual workflow
From the workflow, click and select Middleware.
## Handling public and authenticated requests
When you apply middleware globally — such as an audit log that runs on every API — it will execute on both authenticated **and** public endpoints. Public endpoints (and any endpoint reached without a valid token) don't have an authenticated user, so you can't assume `$auth` is populated.
If your middleware references `$auth.id` directly, an unauthenticated request can fail. The two things to watch for are:
* **Reading the user.** On a request without a valid token, there is no authenticated user, so `$auth.id` throws an error when referencing normally, or a `0` in expressions, rather than a real record ID. Looking up `$auth.id` via an expression is a quick and easy way to handle both cases.
* **Writing the user.** If you store the user ID on a record (like an audit log), the column must accept an empty value. Make the `auth_id` (or `user_id`) column **nullable** in your table so the Add Record step succeeds when no user is present.
Give logging or monitoring middleware an exception method of `silent` so a hiccup in the middleware never blocks the underlying request. Use `critical` only when the middleware is meant to gate access (like the banned-user check above).
The pattern below normalizes the missing user to `null` before logging, so the same middleware works on public and authenticated endpoints alike.
Add a **Create Variable** step (for example, `user_id`) and set its value to an expression, `$auth.id` -- if `auth.id` is populated, this will contain the user ID. If it isn't, it will contain `0`.
Add a **Conditional** step to check if `user_id` = `0`, and if it does, update it to `null`.
Add an **Add Record** step that writes `user_id` along with any other details you want to capture. Make sure the target column allows null values. This will write `null` if no token was sent, or the actual `$auth.id` if a valid token is sent with the request.
```javascript theme={null}
// Logs every request; user_id is null for unauthenticated calls
middleware audit_log {
input {
json vars
enum type {
values = ["pre", "post"]
}
}
stack {
var $user_id {
value = `$auth.id`
}
// Turn the anonymous 0 into a real null for the column.
conditional {
if ($user_id == 0) {
var.update $user_id {
value = null
}
}
}
db.add audit_log {
data = {
user_id : $user_id
request_type: $input.type
created_at : now
}
} as $log_entry
}
response = {log_entry: $log_entry}
response_strategy = "merge"
exception_policy = "silent"
tags = ["logging"]
}
```
# Triggers
Source: https://docs.xano.com/building/logic/triggers
Triggers are workflows that can run based on other events that happen in your workspace.
Before continuing, make sure you're familiar with:
* [Core Components](/building/logic/core-components)
* [Working with Data](/building/logic/working-with-data)
You'll also want to make sure you've already built something to apply triggers to.
Triggers in Xano are workflows that will run only when triggered by another event. You can build triggers for the following events:
* Database Operations
* Adding records
* Editing records
* Deleting records
* Truncating records (clearing the table)
* Realtime Events
* When a user attempts to join a channel
* When a user sends a message to a channel
* Workspace Events
* When a branch is merged
* When a branch is changed to live
* When a new branch is created
* MCP Server Connections
* When a connection is made to an MCP server
For more information on each type of trigger and how to build them, see the following pages:
# AI Agent Trigger
Source: https://docs.xano.com/building/logic/triggers/ai-agent
AI Agent triggers can be created to run any time an agent is called. This is useful for things like logging agent calls, dynamically updating tool instructions, or for modifying the agent's toolset based on certain conditions.
You can find AI Agent triggers by clicking the settings icon in the top-right corner of your agent and choosing **Triggers**.
Agent Triggers offer the following inputs:
`toolset`\
Contains the toolset information, such as the name and instructions.
```json theme={null}
{
"id": 1,
"name": "Agent Name",
"instructions": "Agent Instructions"
}
```
`tools[]`\
An array that contains each tool included in the toolset.
```json theme={null}
{
"id": 1,
"name": "Log Records",
"instructions": "Logs action taken by the agent"
}
```
You can modify the tools or toolset by building logic in the trigger to do so.
# Database Triggers
Source: https://docs.xano.com/building/logic/triggers/database
You can find database triggers on each table by clicking the settings icon in the top-right corner.
Click + Add Database Trigger to create a new database trigger.
You can specify what [Data Sources](/the-database/database-basics/data-sources) the trigger will execute on. If no data source is set, then it will execute on all data sources.
Select the **actions** that will activate this trigger.
**Inserts**\
Any time a record is added to the table
**Updates**\
Any time a record is edited
**Deletes**\
Any time a record is deleted
**Truncates**\
When the content of the database table is cleared
Finally, you can set up custom filters so that the trigger only runs if the record matches certain conditions. For example, if you only want the trigger to run if a new order is created for a user, or a new user is created with a certain role.
***
Database triggers have predefined inputs that contain all of the information you'll need to build a workflow based on the database event.
`new`\
This is the contents of the new record — if you're adding a record, this will contain the contents of the new record, and if you're updating a record, this will contain the contents of the updated record. On deletes and truncates, this will be empty.
`old`\
This is the contents of the old record — if you're deleting or editing a record, this will contain the contents of the record before the change. On inserts and truncates, this will be empty.
`action`\
The action that activated the trigger. Valid options are `insert` `update` `delete` `truncate`
`data source`\
The datasource this trigger has been executed against
***
# MCP Server Triggers
Source: https://docs.xano.com/building/logic/triggers/mcp-servers
MCP triggers can be created to run any time a client connects to the MCP server. This is useful for dynamic updating of server or tool instructions, as well as restricting tools based on the connecting user.
Click the ⋮ icon in the top-right corner of your MCP server and select **Triggers**.
Click Add Trigger to create a new MCP server trigger.
MCP servers currently only support one trigger per server.
Give your trigger a name, description, and tags to help you identify it later. When you're ready, click Save.
Select your newly created trigger to edit it.
MCP Server triggers offer the following inputs:
`toolset`\
Contains the server information, such as the name and instructions.
```json theme={null}
{
"id": 1,
"name": "Server Name",
"instructions": "Server Instructions"
}
```
`tools[]`\
An object array that contains each tool.
```json theme={null}
[
{
"id": 1,
"name": "Tool Name",
"instructions": "Tool Instructions"
},
{
"id": 2,
"name": "Another Tool",
"instructions": "Another Tool Instructions"
}
]
```
You can modify the tools or toolset by building logic in the trigger to do so.
# Realtime Triggers
Source: https://docs.xano.com/building/logic/triggers/realtime
Realtime triggers are created for each channel. Once you've created a realtime channel, click the + Add Channel Trigger button to create a new channel trigger.
Select the **actions** that will activate the trigger.
**Message**\
Any time a new message is sent to the channel
**Join**\
Any time someone attempts to join the channel
The Join trigger fires **before** the user joins the channel, which means it will fire whether or not the user can / is authorized to join that channel. The purpose of this is to allow you to block the user from joining the channel if necessary.
To prevent the user from joining, you can return a `false` response from the trigger. Anything else will allow the user to join the channel.
***
Realtime triggers have predefined inputs that contain all of the information you'll need to build a workflow based on the realtime event.
`Action` and **~~Command~~**\
This will be either 'join' or 'message' depending on what was responsible for executing the trigger.
*****Action and Command currently have the same values, but behind the scenes, the values do not come from the same source. We maintain two separate inputs for the purpose of expanding this functionality in the future.*****
`Channel`\
The channel that this command or message is being sent to
`commandOptions`\
Any options that are provided with the command being sent to the channel
`payload`\
The contents of the command, such as the message body
`client`\
An internal client ID
***
# Workspace Triggers
Source: https://docs.xano.com/building/logic/triggers/workspace
Workspace triggers are workflows that will run when certain actions happen in the workspace.
Workspace triggers are workflows that will run when certain actions happen in the workspace.
Workspace triggers have predefined inputs that can not be changed. These inputs are:
* `to_branch` - The branch that is being merged into
```json theme={null}
{
"id": 1,
"label": "main"
}
```
* `from_branch` - The branch that is being merged from
```json theme={null}
{
"id": 2,
"label": "dev"
}
```
* `action` - The action that triggered the trigger (`branch_live`, `branch_merge`, `branch_new`)
## Creating a Workspace Trigger
Click the⚙️ button in the top-right corner of your workspace dashboard and select Triggers.
Click Add Workspace Trigger.
Give your trigger a name, a description, and any tags you'd like.
Make sure to toggle your Active status to off if you don't want the trigger to run as you build and test.
Select the **action(s)** that will execute this trigger.
**Branch Live**\
Any time a branch status is set to live
**Branch Merge**\
When a branch is merged
**Branch New**\
When a new branch is created
Click Save.
Now, you can build your trigger logic.
Triggers in XanoScript have three sections: **inputs**, **logic**, and **actions**.
**Inputs** are the data that will be available to the trigger.
**Logic** is the actual logic that will be executed when the trigger fires.
**Actions** are the actions that will be executed when the trigger fires.
Here's an example of a basic workspace trigger in XanoScript:
```javascript lines icon="code" Example of a basic workspace trigger in XanoScript theme={null}
workspace_trigger notify_on_branch_change {
description = "Sends an email to the admin on branch activities"
input {
object to_branch {
schema {
int id
text label
}
}
object from_branch {
schema {
int id
text label
}
}
enum action {
values = ["branch_live", "branch_merge", "branch_new"]
}
}
stack {
util.send_email {
api_key = ""
service_provider = "xano"
subject = "Branch activity has occurred"
message = $input.action
bcc = []
cc = []
from = ""
reply_to = ""
scheduled_at = ""
} as $x1
}
actions = {branch_live: true, branch_merge: true, branch_new: true}
}
```
For more information on how to build workspace triggers in XanoScript, see the XanoScript Workspace Triggers documentation.
# Working with Data
Source: https://docs.xano.com/building/logic/working-with-data
Learn how to use, transform, and manipulate data in Xano
Working with data in Xano is a fundamental part of building any application. Xano provides a variety of tools and features to help you work with data, including variables, dot notation, and environment variables.
If you're just starting out, we recommend you read through each of these pages in order.
Learn how to use variables to store and retrieve data in Xano
Learn how to use environment variables to store and retrieve data in Xano
Learn how to use dot notation to target specific pieces of data in Xano
# Dot Notation
Source: https://docs.xano.com/building/logic/working-with-data/dot-notation
Dot notation is used to target specific pieces of data inside of objects and arrays
## What is dot notation?
Dot notation is a way to access specific properties of an object or array using a period (.) to separate the property name from the object or array.
## Using dot notation with objects
Let's say we have the following object:
```json theme={null}
{
"name": "John",
"age": 30,
"created_at": 1736364473744
}
```
If we want to use an Update Variable function to update that `created_at` property to be human readable, we would use dot notation to target that property directly, like this:
This will target `created_at` inside of the object and update it to `Wed, 08 Jan 2025 19:27:53 +0000`.
You can also use dot notation to create new properties inside of an object. Our user object doesn't have a `location` property yet, so we can add it like this:
So, even though the email property doesn't exist, using dot notation to target it will create it for us.
## Using dot notation with arrays
Arrays are a little different than objects in that they are indexed, starting at 0. So, the first item in the array is at index 0, the second item is at index 1, and so on. The `index` just refers to the position of the item in the array.
Let's say we have the following array:
```json theme={null}
[
"apple", // index 0
"banana", // index 1
"cherry" // index 2
]
```
If we want to use an Update Variable function to update the second item in the array to be "orange", we would use dot notation to target that item directly, like this:
This will target the second item in the array and update it to `orange`.
## Using dot notation with complex nested data
You can use dot notation with any combination of nested arrays and objects.
Let's say we have the following array:
```json theme={null}
[
{
"name": "apple",
"details": {
"color": "red",
"price": 1.00
}
},
{
"name": "banana",
"details": {
"color": "yellow",
"price": 0.50
}
}
]
```
If we want to use an Update Variable function to update the price of the second item in the array to be \$0.75, we would use dot notation to target that item directly, like this:
This will target the second item in the array and update the price to \$0.75.
When you need to utilize dots inside of keys (for example, if an external API is returning a key with a dot in it), use double dots to 'escape' the dot and it will remain, instead of being interpreted as dot notation. For example, to access a key named `user.name`, you would use `user..name` in your dot notation. Without the double dots, it would try to access the `name` property of the `user` object.
## Try it out
You can create a new API or custom function and paste the following XanoScript into the editor to see it in action. Feel free to experiment and modify the logic to get a feel for how it works.
```javascript lines icon="code" Dot notation example theme={null}
query dot_notation_example verb=GET {
input {
}
stack {
var $user {
value = {}
|set:"name":"John"
|set:"age":30
|set:"created_at":1736364473744
}
var.update $user.created_at {
value = $user.created_at|format_timestamp:"r":"UTC"
}
var.update $user.email {
value = "john@email.com"
}
var $fruits {
value = []
|push:"apple"
|push:"banana"
|push:"cherry"
}
var.update $fruits.1 {
value = "orange"
}
var $fruits_complex {
value = """
[
{
"name": "apple",
"details": {
"color": "red",
"price": 1
}
},
{
"name": "banana",
"details": {
"color": "yellow",
"price": 0.5
}
}
]
"""|json_decode
}
var.update $fruits_complex.1.details.price {
value = 0.75
}
}
response {
value = {
user : $user
fruits : $fruits
fruits_complex: $fruits_complex
}
}
history = {inherit: true}
}
```
# Environment Variables
Source: https://docs.xano.com/building/logic/working-with-data/environment-variables
Variables that are available across your entire workspace
## What are environment variables?
Environment variables are persistent variables that are available across your entire workspace. Typically, these are used to store things like external API keys or other sensitive information that you need to use across multiple function stacks, without storing it in a database table.
Environment variables can be read in any logic or workflow, but they can not be modified from anywhere but this settings panel, so it's best to only use them for things that you don't need to change often.
## Adding Environment Variables
Click the icon in the upper-right corner to open **Settings**.
On the next screen, click 'Manage' to edit your environment variables.
Click '+ Add Variable' at the bottom of the panel that opens to add a new variable.
Give your environment variable a name that you can easily recognize; this is how you'll identify it when calling it in function stacks. Then, supply the value.
## Using Environment Variables
Environment variables are available in any logic or workflow from a value dropdown under **ENV**.
## Xano-generated Environment Variables
Xano maintains several environment variables you can use.
| Variable | Description |
| ---------------------- | ---------------------------------------------------------------------------- |
| `$remote_ip` | Resolves to the IP address of the individual accessing the API endpoint. |
| `$http_headers` | A text array of headers that are sent to the API endpoint. |
| `$api_baseurl` | Contains the base URL of the active endpoint. |
| `$request_uri` | Contains the URI being accessed from the API. |
| `$request_method` | The HTTP method (`GET`, `POST`, `DELETE`, etc.) of the incoming API request. |
| `$request_querystring` | Contains the query string of the URI being accessed from the API. |
| `$request_auth_token` | Contains the authorization token of the API request. |
| `$datasource` | Indicates which datasource is being used. |
| `$branch` | Indicates which branch is being used. |
# Variables
Source: https://docs.xano.com/building/logic/working-with-data/variables
Variables are used to store temporary information that you need to access later in a workflow
## What are variables?
Variables are like containers or labels that store information you want to use later in a workflow. Think of them as named boxes where you can keep different types of items, such as numbers, words, or lists. You give each box a name so you can easily find and use the information it holds whenever you need it in your project. This makes it simple to update or change the data without needing to rewrite everything.
Variables are temporary and exist only while a workflow is running, used for storing information you need to access quickly, whereas values in a database are like records in a filing cabinet, stored permanently until you decide to update or delete them, accessible across various workflows and sessions. This makes databases ideal for managing large sets of data over time, and variables more appropriate for temporary data handling.
## Creating a variable
You'll find this function as a default favorite at the top of the function menu, or inside of the Data Manipulation section.
The variable name should be a descriptive name that you can easily recognize. Names can only contain letters, numbers, and underscores, and must start with a letter. The value can be anything you'd like, from simple text and integers all the way to large, complex data types.
You can also just establish an empty variable by leaving the value blank if you're going to add a value later.
## Using a variable
Inside of your logic, you can reference the variable by using the variable name. You'll find it under the **VAR** dropdown, or you can just type the variable name directly into the value field.
Need to specify a value that's the same as the variable name? Click the **CONST** section and choose the `text` data type.
## Updating a variable
If you need to update a variable, you can use the **Update Variable** function. This will overwrite the existing value with the new one.
Remember, you can use [dot notation](/building/logic/working-with-data/dot-notation) to target a specific piece of data inside of the variable if it's an array or object.
## Deleting a variable
There is no 'delete variable' function, but you can overwrite the variable with an empty value to effectively delete it. However, usually this is not necessary, as variables are automatically deleted when the logic is complete.
# Building Visually
Source: https://docs.xano.com/building/visually
Learn about how Xano enables you to build your backend without code
Whether you're a developer or a no-coder, Xano gives you two powerful ways to visually build backend logic — choose the style that fits your brain. You're not locked in, either -- switch between the different building modes at any time.
| | Canvas View | Function Stack |
| -------------- | ----------------------------- | ------------------------- |
| Best for | Visual thinkers | Step-by-step thinkers |
| Style | Node-based, story view | Linear, ordered list |
| Learning curve | Very low | Low-medium |
| Ideal use | Rapid prototyping, non-coders | Complex flows, developers |
## The Canvas View
The **Canvas View** is a newer visual builder that is designed to be more user-friendly and intuitive. It adopts a well-loved node based view, giving you a more storytelling view of your logic with all of the visual editing capabilities you've come to expect without sacrifices.
## The Function Stack
Xano's original visual builder is called the **Function Stack**. It's a hybrid between a traditional code view and a visual builder. It shows you each function in execution order, but in a way that is understandable for non-technical users.
# Building with AI
Source: https://docs.xano.com/building/with-ai
Learn how to build with AI in Xano using our AI Assistants
Build your entire backend from a single prompt — right inside Xano. Xano Agent creates tables, APIs, functions, middleware, and more, with a built-in review flow before anything goes live.
## Using XanoScript in an IDE
Many IDEs, like VS Code and Cursor, come with powerful AI help built right in. With our VS Code extension, it automatically knows how to write XanoScript, so it can build your entire backend, or just help you ideate and iterate.
Get the VS Code extension to start building your backend with AI
## AI Assistants
Xano provides a suite of AI Assistants to help you build your backend with AI.
Build logic for APIs, custom functions, and background tasks.
Design, add to, or update your database.
Generate SQL queries for the Direct Database Query function.
Write Lambda functions in JavaScript or TypeScript.
Build templates for AI prompts, HTML, and more using dynamic data.
Craft prompts for your AI Agents.
Create requests for external APIs.
Set up your Xano workspace with AI.
## Xano MCP Server
The Xano MCP Server is a collection of tools that you can connect to using your favorite MCP client of choice, such as Anthropic's Claude, Cursor, or Windsurf, to chat with your Xano backend.
Learn how to use the Xano MCP Server with an MCP client to build your entire backend with AI
## Xano Metadata API
The Xano Metadata API is a RESTful API that allows you to programmatically manage your Xano workspace schema and content. There are endpoints that, among other things, accept XanoScript, which you can build with your favorite AI model and then use the Metadata API to push. In addition, the API can manage all other content in your workspace, which means you can use it for things like database management, sample data generation, and more.
Learn how to use the Xano Metadata API to manage your Xano workspace schema and content
# Xano Agent
Source: https://docs.xano.com/building/xano-agent
Build your entire backend with a single prompt using the AI-powered Xano Agent
Xano Agent is an AI assistant built into Xano that can create, modify, and manage your backend through natural language. Describe what you want — database tables, API endpoints, middleware, functions — and Xano Agent builds it for you in XanoScript, ready to review and publish.
Everything Xano Agent creates is standard Xano — you can open it in the [visual editor](/building/visually), edit it as [XanoScript in your IDE](/xano-cli/get-started), or refine it with the [AI assistants](/building/with-ai). These are all different ways to work with the same underlying resources, so you're never locked into one approach.
**Looking for AI Agents you can build and deploy as part of your backend?** See [AI Agents](/ai-tools/agents) instead.
## How it works
Xano Agent operates directly inside your workspace. You chat with it, it proposes a plan, writes the XanoScript, and presents the changes for your review before anything goes live.
Open Xano Agent from inside your workspace. You'll see a chat interface with a file browser on the left showing your workspace contents.
Type a prompt describing your backend requirements. Xano Agent works best with detailed, specific requests. For example:
> Build a backend for a simple Instagram clone that supports both image and video uploads, threaded comments, likes, follows, private accounts, "close friends" lists for private / limited posts, and direct messaging.
Xano Agent will analyze your request and present a proposed plan — including the database schema, API groups, and endpoints it intends to create.
As Xano Agent builds, you can view the generated XanoScript in the code editor. The file browser updates in real-time as new tables, APIs, and other resources are created.
Toggle between **Summary** and **XanoScript** views to inspect the logic from different angles.
If you're using the Agent to make modifications to something instead of starting fresh, you'll also be able to take advantage of the Diff view to see the changes easily.
Click **Push to Draft** once you're ready to apply the changes the Agent built to your workspace. You can always continue the conversation now to iterate, or come back to it later.
## Publishing
When you're satisfied with what you have built using the Xano Agent, click **Push to Draft** to stage your changes.
Sometimes, you may be asked to **Confirm required publish** for items that don't support draft states. Currently, this includes:
* Database tables
* API groups
Xano will show you exactly which items will be published directly so there are no surprises.
For the rest, it will be pushed to a draft state for you to publish whenever you're ready.
## What Xano Agent can build
Xano Agent has full access to your workspace and can create or modify:
* **Database tables** — schema design, field types, relationships, and indexes
* **API endpoints** — full CRUD, authentication, input validation, and custom logic
* **Custom functions** — reusable logic blocks
* **Middleware** — authentication checks, rate limiting, request preprocessing
* **Background tasks** — scheduled or event-driven workflows
## Tips for effective prompts
* **Be specific** — include field names, data types, relationships, and business rules when possible.
* **Describe the domain** — a sentence of context about your app helps Xano Agent make better schema decisions.
* **Iterate** — start with a broad request, review the output, then ask for refinements in follow-up messages.
* **Reference existing resources** — if you already have tables or APIs, mention them so Xano Agent builds on top of what's there.
## Other ways to build in Xano
Xano Agent is one of several ways to build your backend. They all produce the same output and work with the same resources — pick whichever fits the task at hand, or combine them.
| | Xano Agent | [Visual editor](/building/visually) | [AI Assistants](/building/with-ai) | [CLI + IDE](/xano-cli/get-started) |
| --------------- | ---------------------------------------------------- | ----------------------------------- | ------------------------------------------------ | ----------------------------------- |
| **Where** | Inside Xano | Inside Xano | Inside Xano | Local IDE (VS Code, Cursor, etc.) |
| **Scope** | Full workspace — tables, APIs, functions, middleware | Full workspace | Individual features (logic, database, SQL, etc.) | Full workspace via XanoScript files |
| **Interaction** | Chat-based, multi-step | Point-and-click | Single-purpose per assistant | AI agent writes `.xs` files locally |
| **Review flow** | Built-in diff view + push to draft | Live editing | Inline suggestions | Git diff + CLI push |
# CI/CD
Source: https://docs.xano.com/ci-cd
Learn more about CI/CD inside of Xano
**Quick Summary**
CI/CD stands for \*\*continuous integration and continuous delivery \*\*and is a set of best practices that define how new logic is tested and deployed.
While fully automated CI/CD is not available today in Xano, we have a number of features designed to replicate the most important pieces of the concept, outlined below.
Each feature mentioned below offers its own in-depth documentation, which we also recommend reviewing.
## CI/CD Explained
CI/CD is a technique used in software development to make the process of updating applications faster and more reliable.
CI, or Continuous Integration, involves regularly adding small updates to the codebase, helping developers catch and fix errors quickly. CD, or Continuous Delivery, ensures these updates can be automatically tested and deployed to production environments seamlessly. Together, these practices help deliver new features and improvements to users more efficiently, ensuring a better, more stable experience.
In Xano, you can think of any function stacks you're building as your **codebase**. Features such as **branching/merging, unit and workflow tests**, and **triggers** can all play a role in building a seamless CI/CD-style workflow in Xano for you and your team.
## Achieving CI/CD in Xano
Typically, you'll have at least three environments for proper development.
* **Dev** - This is where you build updates and new features
* **Stage** - This is where you deploy changes and initiate testing to ensure they work as expected, and there are no new bugs or regressions (old bugs returning) introduced
* **Prod** - This is the production environment that serves the live experience to your users
These environments in Xano are best laid out differently, depending on your plan.
* **Launch / Self-Serve Plans**: Use [Branching & Merging](/team-collaboration/branching-and-merging) and create separate branches for dev, stage, and prod. Your frontend should typically only be calling production endpoints, but you can also deploy a second frontend for testing that defaults to stage or dev
* **Scale, Pro, Custom or Enterprise Plans with Xano Link**: Deploy your changes to separate workspaces using [Xano Link](/xano-features/advanced-back-end-features/xano-link)
* **Enterprise or Custom Plans with Tenant Center**: Create separate tenants in your [Tenant Center](/enterprise/enterprise-features/tenant-center) for each environment, and deploy releases to them
You should always be building tests for your function stacks using our [Unit Tests](/testing-debugging/unit-tests) and [Test Suites](/testing-debugging/test-suites) features. Unit Tests are designed to run a test on a single function stack (such as a sign-up API), and Test Suites (Workflow Tests) are designed to check what would be a typical multi-step flow for your application (such as a user signing up, purchasing a subscription plan, and receiving a confirmation email).
To ensure full coverage, make sure that your tests not only check for positive results, but they also check for proper error handling when things go wrong. The goal is not necessarily to achieve 100% success, but to achieve 100% coverage for all possible scenarios.
Deploy your changes to Stage and run your [Unit Tests](/testing-debugging/unit-tests) and [Test Suites](/testing-debugging/test-suites) to ensure everything is behaving as expected.
If you have tests that fail, it would be recommended to head back to your development environment and make any corrections necessary, and deploy those new changes back to Stage to test again.
Once you've confirmed that your tests pass and you have full coverage, you can push your changes to your production branch or environment.
**How do tests impact my database?**
[Test Suites](/testing-debugging/test-suites) create a duplicate copy of your database, temporarily, just for testing. So, if your production database is large or complex, you may have trouble completing your tests or experience additional complications. It is strongly recommended to utilize [Data Sources](/the-database/database-basics/data-sources) to navigate around this potential issue.
You can also run tests with no database **(Empty)** if a database is not necessary for that specific test, or if your tests can run from an empty database, such as if they're only adding data that isn't used later anywhere.
## Additional Notes
### Managing Environment Variables
If you're working with external services, you may require different configurations between your development, stage, and production environments, such as different API keys. Typically, you'd store these in your [Environment Variables](/the-function-stack/environment-variables).
* **If you're using Branching/Merging**, you'll be limited to storing all environment variables together. You can use statements like [Get Environment Variables](/the-function-stack/functions/utility-functions#get-environment-variables) to manually parse all available environment variables and retrieve the ones necessary depending on the branch you're on.
* **If you're using Xano Link**, each workspace can contain its own environment variables, and no additional logic is necessary.
* **If you're using Tenant Center**, you have the ability to manage each tenant's environment variables from the Tenant Center. Each tenant can contain its own environment variables, and no additional logic is necessary.
### Managing Development Across Teams
Each team or team member should be responsible for developing specific features. Ideally, these features would not cross-contaminate function stacks that separate teams or team members might be working on.
If you find that multiple team members need to work on the same function stacks, we have [Team Collaboration](/team-collaboration/realtime-collaboration) features built right into Xano to ensure that the experience is as smooth as possible.
If your plan has access to RBAC (Role-based Access Control), it is imperative that you manage permissions properly to ensure that only specific team members can push changes from development to stage, and even more so from stage to production. Be sure to review our documentation on [Role-based Access Control (RBAC)](/team-collaboration/role-based-access-control-rbac) for more information.
### Using Mock Responses for Test-Driven Development
For certain steps, you should also be [Mocking Responses](/testing-debugging/unit-tests#mocking-responses) both for the sake of speed and consistency when running your tests.
As an example, if you're calling an external API and want to ensure that you always test with the same response, you can add a mock response to your unit test to accommodate that. This allows for **test driven development**, or essentially being able to have different team members build endpoints that you'll be relying on, but might not be complete yet. Adding a mock response allows you to continue working alongside the other team member, instead of having to wait.
# Browse Integrations
Source: https://docs.xano.com/connect
# AI App Builders
Source: https://docs.xano.com/connecting-to-a-frontend/ai-app-builders
Connect your Xano backend to AI app builders like Lovable, Bolt, and Replit using your auto-generated Swagger/OpenAPI docs.
AI app builders can ingest your Xano API documentation to automatically generate a fully connected frontend — complete with API calls, forms, authentication flows, and more. All you need is your Swagger/OpenAPI spec from Xano.
***
## Step 1: Enable Combined Swagger Documentation
***
## Step 2: Import into Your AI Builder
[Lovable](https://lovable.dev/) can import your OpenAPI spec to generate a complete frontend application.
1. Copy the **OpenAPI/JSON link** from your Xano Swagger documentation page.
2. In Lovable, provide the spec URL or upload the downloaded JSON file when starting a new project or in your prompt.
3. Lovable will generate pages, components, and API integration code based on your endpoints.
Be specific in your Lovable prompts about which endpoints to use and how the UI should behave. The more context you provide alongside the spec, the better the results.
[Bolt](https://bolt.new/) can use your OpenAPI spec to understand your backend and generate a connected frontend.
1. Download the JSON spec from your Xano Swagger documentation page.
2. In Bolt, upload the spec file or paste the spec URL as part of your project context.
3. Reference specific endpoints in your prompts to guide Bolt in building the right pages and functionality.
[Replit](https://replit.com/) supports AI-assisted development that can work with your OpenAPI spec.
1. Download the JSON spec from your Xano Swagger documentation page and add it to your Replit project files.
2. Reference the spec in your prompts to the Replit AI agent, asking it to build API integrations based on the documented endpoints.
3. Replit will generate code that calls your Xano APIs directly.
***
## Best Practices
* **Start with a clear objective** — Know what your MVP looks like before you start prompting. Define the core screens, user flows, and which API endpoints each screen needs.
* **Use version control** — Store your generated app code in Git so you can roll back if the AI produces something unexpected. This also makes it easier to start fresh conversations with context.
* **Iterate in small steps** — Rather than asking the AI to build everything at once, break your app into pieces (auth flow, dashboard, settings page, etc.) and build them one at a time.
* **Review the generated API calls** — Double-check that the AI is calling the right endpoints with the right parameters. AI builders sometimes hallucinate endpoints that don't exist in your spec.
* **Keep your spec up to date** — If you add or change endpoints in Xano, re-export your Swagger spec and re-import it into your AI builder so it stays in sync.
***
## Quick Demo
Here's a quick demonstration of importing Xano's Swagger documentation into ChatGPT and getting a functional app back:
# Custom Coded Apps
Source: https://docs.xano.com/connecting-to-a-frontend/custom-coded-apps
Connect your Xano backend to a custom-coded frontend using the JS SDK, standard REST calls, or AI-assisted development with your Swagger docs.
If you're building a frontend with a framework like **Next.js**, **React**, **Vue**, **Svelte**, or any other language/framework, you can connect to Xano using standard REST API calls, the official JS SDK, or by leveraging AI coding assistants with your auto-generated Swagger docs.
***
## Option 1: AI-Assisted Development with Swagger Docs
The fastest way to integrate Xano into a custom-coded app is to provide your auto-generated Swagger/OpenAPI spec to an AI coding assistant. The AI can then generate type-safe API clients, data fetching hooks, and full integration code based on your actual endpoints.
### Enabling Combined Swagger Documentation
### Using with AI Coding Assistants
[Claude Code](https://docs.anthropic.com/en/docs/claude-code) is Anthropic's CLI tool for AI-assisted development. You can provide your Swagger spec directly to Claude Code for it to generate integration code, API clients, and types.
1. Download your combined Swagger JSON spec from Xano and save it in your project (e.g., `docs/xano-api.json`).
2. Reference the spec when asking Claude Code to build your integration:
```
# Example: Ask Claude Code to generate an API client
"Using the OpenAPI spec in docs/xano-api.json, generate a TypeScript
API client with functions for each endpoint."
```
Claude Code will read the spec and generate accurate code matching your actual API endpoints, request bodies, and response types.
[Cursor](https://cursor.sh/) is an AI-powered IDE that can use your API documentation as context.
1. Download your combined Swagger JSON spec and save it in your project directory.
2. Add the spec file to your Cursor project context so the AI can reference it.
3. Ask Cursor to generate API calls, hooks, or full pages — it will use the spec to produce accurate code.
```
# Example prompt in Cursor
"Using the OpenAPI spec, create a React hook that fetches
the list of products with pagination support."
```
[GitHub Copilot](https://github.com/features/copilot) can use your Swagger spec as context when generating code.
1. Download your combined Swagger JSON spec and save it in your project.
2. Open the spec file alongside the file you're working in, or reference it in Copilot Chat.
3. Copilot will use the endpoint definitions to generate accurate API calls.
***
## Option 2: Xano JS SDK
The [Xano JS SDK](https://gitlab.com/xano/js-sdk) provides helpers for authentication, API calls, and real-time features. It works in any JavaScript/TypeScript environment (browser, Node.js, etc.).
### Installation
```bash theme={null}
npm install @xano/js-sdk
```
### Basic Usage
```ts theme={null}
import XanoClient from '@xano/js-sdk';
const xano = new XanoClient({
instanceBaseUrl: 'https://your-instance.xano.io',
// Optionally set a default API group
// realtimeConnectionHash: 'your-hash' // for realtime features
});
// Make an authenticated request
xano.setAuthToken('your-jwt-token');
const response = await xano.get('/api:your-group/endpoint');
console.log(response.getBody());
```
### Authentication Flow Example
```ts theme={null}
// Sign up
const signupResponse = await xano.post('/api:your-group/auth/signup', {
email: 'user@example.com',
password: 'securepassword',
});
const token = signupResponse.getBody().authToken;
xano.setAuthToken(token);
// Access protected endpoint
const me = await xano.get('/api:your-group/auth/me');
console.log(me.getBody());
```
For full SDK documentation, see the [Xano JS SDK on GitLab](https://gitlab.com/xano/js-sdk).
***
## Option 3: Standard REST Calls (fetch / axios)
Xano APIs are standard REST endpoints. You can call them with `fetch`, `axios`, or any HTTP client in any language.
### Fetch Example (TypeScript)
```ts theme={null}
const XANO_BASE = 'https://your-instance.xano.io/api:your-group';
async function getProducts(page = 1) {
const res = await fetch(`${XANO_BASE}/products?page=${page}`, {
headers: {
Authorization: `Bearer ${token}`,
'Content-Type': 'application/json',
},
});
if (!res.ok) throw new Error(`Xano error: ${res.status}`);
return res.json();
}
```
### POST Example
```ts theme={null}
async function createProduct(data: { name: string; price: number }) {
const res = await fetch(`${XANO_BASE}/products`, {
method: 'POST',
headers: {
Authorization: `Bearer ${token}`,
'Content-Type': 'application/json',
},
body: JSON.stringify(data),
});
if (!res.ok) throw new Error(`Xano error: ${res.status}`);
return res.json();
}
```
***
## Tips
* **Environment variables** — Store your Xano base URL and API group paths in environment variables rather than hardcoding them.
* **Authentication** — Most Xano APIs use JWT-based auth. Call your `auth/login` or `auth/signup` endpoint to get a token, then pass it in the `Authorization: Bearer ` header.
* **Branching** — Use [Xano branches](/team-collaboration/branching-and-merging) to develop and test backend changes without affecting your production frontend.
* **CORS** — Xano handles CORS automatically. If you run into issues, check your API group's CORS settings.
# No-Code App Builders
Source: https://docs.xano.com/connecting-to-a-frontend/no-code-builders
Connect your Xano backend to no-code platforms like WeWeb, Bubble, and others using native integrations or REST APIs.
No-code app builders can connect to Xano through **native integrations** (plugins built specifically for Xano) or through **standard REST API calls** using your Swagger/OpenAPI documentation. The approach depends on your platform.
***
## WeWeb
WeWeb has dedicated Xano plugins for both data fetching and authentication, making it the most tightly integrated no-code option.
### Data Source Plugin
Supply your **Personal Access Token** (PAT) from the [Metadata API](/xano-features/metadata-api). This allows WeWeb to discover your API groups and endpoints automatically.
Configure collections for each data set you need. You can set global headers at the plugin or collection level.
No additional configuration is needed to pass auth tokens with your data requests.
[WeWeb Xano Data Source Documentation](https://docs.weweb.io/plugins/data-sources/xano-data.html)
### Auth Plugin
The WeWeb Xano Auth Plugin handles signup, login, logout, gated content, and role-based redirects.
[WeWeb Xano Auth Plugin Documentation](https://docs.weweb.io/plugins/auth-systems/xano-auth.html)
***
## Bubble
Bubble can connect to Xano in two ways: through a community-built Xano connector, or through Bubble's native API Connector.
### Xano Connector Plugin
A community-driven plugin built around the official Xano JS SDK. It simplifies authentication and supports real-time features.
[Bubble Xano Connector Guide](https://elibeachy.gitbook.io/xano-connector/)
### Bubble API Connector
Use Bubble's built-in API Connector to configure Xano endpoints manually. You'll copy endpoint URLs, methods, headers, and request/response structures from your Swagger documentation.
We recommend using the **combined (workspace-level) Swagger documentation** so you have all endpoints in one place. See [Swagger/OpenAPI Docs](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation) for how to enable it.
Go to **Plugins → API Connector** and add a new API.
Using your Swagger docs as reference, set the URL, method, headers (`Authorization: Bearer `), and request body for each endpoint you need.
Bubble requires you to initialize each API call to detect the response structure. Make sure your Xano backend has test data available.
[Bubble + Xano API Connector Guide](https://www.xano.com/learn/Connect-Xano-Bubble/)
***
## Other No-Code Platforms (REST API)
Any no-code platform that supports making HTTP/REST requests can connect to Xano. The general approach is the same regardless of the platform:
### General Steps
Open your [Swagger/OpenAPI documentation](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation) in Xano. We recommend enabling **combined (workspace-level) documentation** so you have all endpoints in one place. Copy the base URL and endpoint paths you need.
In your no-code platform's API/HTTP request feature, set up:
* **URL**: Your Xano endpoint URL (e.g., `https://your-instance.xano.io/api:your-group/endpoint`)
* **Method**: GET, POST, PATCH, DELETE, etc. (as documented in Swagger)
* **Headers**: `Content-Type: application/json` and `Authorization: Bearer ` for protected endpoints
* **Body**: JSON request body for POST/PATCH requests, matching the schema in your Swagger docs
Call your `auth/login` or `auth/signup` endpoint to get a JWT token. Store the token and include it in the `Authorization` header for subsequent requests.
Use your platform's data binding features to map the JSON response from Xano to your UI components.
### Common Platforms
This approach works with platforms like:
* **FlutterFlow** — Use the API Call feature to configure REST endpoints
* **Adalo** — Use Custom Actions or the API Connector to call Xano endpoints
* **Softr** — Connect via the REST API integration
* **Glide** — Use the API integration feature with your Xano endpoints
* **AppGyver / SAP Build Apps** — Configure REST API data sources
If your no-code platform supports importing an **OpenAPI/Swagger spec**, you can import your combined Swagger JSON directly instead of configuring each endpoint manually. Check your platform's documentation for OpenAPI import support.
***
## Tips
* **Personal Access Tokens** — Platforms with native Xano integrations (like WeWeb) use PATs from the [Metadata API](/xano-features/metadata-api) to discover your API groups. This is separate from the JWT tokens your app's users will use.
* **CORS** — Xano handles CORS automatically. If you encounter issues, check your API group's CORS settings.
* **Branching** — Use [Xano branches](/team-collaboration/branching-and-merging) for backend changes so your production frontend stays stable while you develop.
* **Platform docs first** — For platform-specific configuration (plugin settings, data binding, deployment), the best source of truth is always the platform's own documentation.
# Connecting a Frontend
Source: https://docs.xano.com/connecting-to-a-frontend/overview
Connect your Xano backend to any frontend — whether you're writing code, using an AI app builder, or building with a no-code platform.
Xano works with any frontend that can make HTTP requests. How you connect depends on how you're building your app.
Building with Next.js, React, Vue, or another framework? Use the Xano JS SDK, standard REST calls, or let AI coding assistants like Claude Code and Cursor generate your integration from your Swagger docs.
Using Lovable, Bolt, or Replit? Import your auto-generated Swagger/OpenAPI spec and let the AI builder wire everything up for you.
Using WeWeb, Bubble, or another no-code platform? Connect with native Xano plugins or standard REST API calls.
***
## Xano's Auto-Generated Swagger Docs
No matter which approach you choose, Xano's auto-generated [Swagger/OpenAPI documentation](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation) is your best friend. Every API you build is automatically documented with endpoints, request/response schemas, and authentication requirements.
We recommend enabling **workspace-level (combined) Swagger documentation** so you have a single URL that covers all of your API groups. This is the easiest way to share your full API surface with any frontend tool, AI builder, or team member. See [Swagger/OpenAPI Docs](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation) for setup instructions.
## Other Ways to Connect
* **[Static Hosting](/xano-features/static-hosting)** — Host your frontend directly in Xano alongside your backend.
* **[Realtime (WebSockets)](/realtime/realtime-in-xano)** — Add real-time features using the Xano JS SDK or WebSocket connections.
# Deployment
Source: https://docs.xano.com/deployment
Overview of deployment options and resources for taking your Xano projects from development to production.
Deploying a Xano backend means preparing your project for **production use**, ensuring your APIs, data, and integrations are stable and accessible to end users.\
This page serves as a **landing hub** for all deployment-related topics in Xano.
***
## Key Deployment Topics
### [Publishing Your Logic](/the-function-stack/building-with-visual-development#publishing)
Learn how to **publish** your APIs, Custom Functions, Background Tasks, Triggers, Middleware, and AI tools so that your live environment reflects your latest work.\
This guide covers publishing workflows and best practices for releasing updates safely.
### [Static Hosting](/xano-features/static-hosting)
Learn how to host your static frontend files on your Xano instance. This is great for hosting your frontend right alongside your backend, or even just deploying quick tests as you build and iterate on your application.
### [Branching & Merging](/team-collaboration/branching-and-merging)
Use **branching** to work on new features without affecting production.\
When ready, merge your changes back into the main branch to deploy updates confidently.\
This page explains branching strategies for teams, conflict resolution, and merging guidelines.
### [Swagger/OpenAPI Documentation](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation)
Your Xano API is automatically documented with an **OpenAPI (Swagger)** specification.\
Learn how to share this spec with developers, AI copilots, or frontend tools to streamline integration and ensure accurate deployments.
### [Connecting to a Frontend](/connecting-to-a-frontend)
Once your backend is ready, connect it to a frontend application—whether it’s a **no-code builder** like WeWeb or Bubble, an **AI builder** like Lovable, or a **custom codebase** in TypeScript.\
This guide outlines the different connection methods and how to keep your frontend in sync with your live backend.
***
## Deployment Workflow at a Glance
1. **Develop**: Build and test your API endpoints, database schema, and logic in a safe branch or staging environment.
2. **Test**: Test your API endpoints, database schema, and logic in a safe branch or staging environment.
3. **Document**: Review your automatically generated Swagger/OpenAPI documentation to ensure endpoints are clear and up to date.
4. **Publish**: Push your changes to production.
5. **Connect**: Link your live backend to your frontend or external services using the provided API endpoints.
***
> 💡 **Tip**: For advanced teams, combine branching, publishing, and OpenAPI documentation to create a robust CI/CD workflow, making deployments predictable and repeatable.
# Deployment Readiness
Source: https://docs.xano.com/deployment-readiness
Validate performance, tests, data safety, and scale before pointing real users at your Xano backend.
**Quick summary**
Deployment readiness is the work you do *before* sending production traffic to your backend: reviewing performance, building and running tests, validating workflows against safe data, and — if traffic warrants it — load testing. This page is the performance and reliability companion to the [Pre-Launch Security Checklist](/security/pre-launch-security-checklist). You should work through both before you launch.
Deployment readiness is a checkpoint, not a milestone. It's a structured pass through your backend that answers four questions: Does it perform? Does it behave correctly? Can you change it safely? Will it hold up under the traffic you expect? Each section below walks through one of those questions, what to check inside Xano, and what "good enough to move on" looks like.
This guide focuses on backend readiness. If you're connecting a frontend, you'll find a related staging pattern in the [Test data sources](#use-test-data-sources-to-dry-run-your-application) section using the `X-Data-Source` header.
***
## When to use this guide
Work through this guide when you are:
* About to point production traffic at a new Xano workspace or instance for the first time
* Releasing a significant feature that changes critical endpoints, schema, or background tasks
* Migrating from a sandbox or trial workspace to a paid plan
* Preparing for a marketing launch, partner integration, or any event that could change your traffic shape
* Re-evaluating an existing production backend after sustained growth or recurring incidents
You don't need to repeat every section for small changes — but the [checklist](#deployment-readiness-checklist) at the end is a good periodic review even after launch.
***
## The readiness flow
You'll move from narrow, fast checks to broader, slower ones. Each layer builds on the previous:
1. **Review performance baselines** — understand how your backend behaves today.
2. **Build unit tests and workflow tests** — lock in correct behavior for individual endpoints and end-to-end flows.
3. **Dry-run with a test data source** — exercise your application against safe data that mirrors production.
4. **Load test (if traffic warrants it)** — confirm the backend holds up under realistic concurrency.
The sections below follow this order. You can stop at the layer that matches your risk profile, but skipping earlier layers tends to surface issues in expensive places.
***
## Review performance baselines
### Why this matters
Performance issues that look minor in development can dominate latency in production. Reviewing your current baselines gives you a real picture of which endpoints are slow, which are hot, and which are both — the third category is where launch problems concentrate.
### What to check
* Average execution time for high-traffic endpoints
* The slowest database queries, especially Query All Records operations
* External API calls and Lambda functions — these add latency outside your direct control
* Background tasks that process large datasets
* Endpoints that return large payloads
### How to do it in Xano
From the sidebar, switch to the **Monitor** tab and select [Performance Insights](/maintenance-monitoring-and-logging/performance-insights).
Use 24 hours for very active workspaces and 7 or 30 days for newer ones. Aim for a window that reflects realistic usage patterns rather than a quiet period.
The slowest endpoints matter, but so do the busiest. The intersection of slow *and* busy is where to start optimization work.
Open [Request History](/maintenance-monitoring-and-logging/request-history) to see individual responses, input and output sizes, and any error responses. Filter by duration to spot outliers that don't show up clearly in averages.
### What to look for
* Endpoints that exceed your expected response budget for their use case (an interactive UI tolerates much less latency than a background sync)
* Query All Records calls without filters, pagination, or indexes
* Repeated external API calls that could be batched, cached, or moved to a background task
* Endpoints with spiky latency rather than steady response times — spikes often point to lock contention or external dependency variability
* Background tasks whose runtime is creeping up over time
### Common issues to fix
* Unbounded Query All Records — add filters, pagination, or indexes
* External API calls inside loops — batch, cache, or move them to background work
* Function stacks fetching more data than they use — trim the response shape
* Synchronous handlers doing heavy work that belongs in a background task
* Missing indexes on columns used for filters, joins, or sorts
### Before moving on
You should understand which endpoints will see the most traffic, how fast they run today, and which slow paths you've fixed or knowingly deferred.
***
## Build unit tests and workflow tests
Tests are the cheapest place to catch regressions. Xano provides two kinds, and they answer different questions.
| Test type | Scope | Answers |
| ----------------- | --------------------------------------- | -------------------------------------------------------------------------- |
| **Unit test** | A single function stack or API endpoint | Given this input, does this one piece of logic return the expected output? |
| **Workflow test** | A sequence of endpoint calls | Does this real user journey complete correctly from start to finish? |
You want both. Unit tests catch logic errors quickly, in isolation. Workflow tests catch the integration problems that only appear when steps depend on each other — wrong handoff between endpoints, missing fields, broken state transitions.
### Why this matters
Without tests, every deployment is a hope. Tests turn deployment into a verifiable claim: the behavior you depended on yesterday still works today. They also become essential the moment more than one person edits the backend.
### What to check
Make sure each of these is covered:
* **Critical paths** — the small set of flows your business cannot afford to have broken. Concrete examples:
* Authentication: sign up, log in, password reset, token refresh
* Money: checkout, refund, subscription change
* Data integrity: any endpoint that writes to a table referenced by other tables
* Communications: order confirmation emails, notification webhooks
* **Error branches** — invalid inputs, missing required fields, expired tokens, denied permissions
* **Edge cases for your data shape** — empty strings, null values, maximum-length inputs, unusually large arrays
### How to do it in Xano
From any API endpoint or custom function, use **Run & Debug** with a known input. When you have the result you expect, click **Create Unit Test**.
Define **Expects** statements to assert the response shape — for example, `response.authToken is defined` or `response.user.id is a number`. Add multiple Expects to cover the parts of the response your callers depend on. See [Unit Tests](/testing-debugging/unit-tests) for the full reference, including [mocking external responses](/testing-debugging/unit-tests#mocking-responses) so tests don't depend on third-party uptime.
From the **Test & Deploy** tab, open **Workflow Tests** and create a new test suite. Add **Run Stack** steps to call APIs in the order a real user would, and **Test Expression** steps between them to assert that the right state moved forward.
Useful workflow examples:
* Sign up → email verification → profile setup
* Add to cart → apply coupon → checkout → payment → order confirmation
* File upload → background processing → status check → export
See [Test Suites](/testing-debugging/test-suites) for the full reference.
From **Unit Tests** in the **Test & Deploy** tab, click **Run Test Suites** to execute every test. The results page shows coverage (the share of function stacks that have tests) and success rate.
Filter by **Failed Only** when you're triaging. Treat any new failure as a blocker until you've either fixed it or explicitly accepted it.
### What to look for
* Every critical path has at least one workflow test and unit tests covering its underlying endpoints
* Failure scenarios are tested, not only happy paths
* External dependencies are mocked so test results don't fluctuate with third-party availability
* The full suite runs cleanly end-to-end, not just individual tests in isolation
### Common issues to fix
* Workflow tests that share state and pass only when run in a specific order — make each test set up its own data
* Tests that depend on auth tokens which expire — refresh tokens as part of test setup
* Coverage numbers driven by trivial tests on non-critical functions while critical paths remain uncovered
* Flaky tests left in the suite — fix or quarantine them, don't ignore them
### Before moving on
You should be able to run the full suite and read the results without surprise. Every critical path should be covered by tests, and you should know which failures (if any) you've decided are acceptable for launch.
***
## Use test data sources to dry-run your application
Never iterate on live production data. Xano [Data Sources](/the-database/database-basics/data-sources) let you keep separate, isolated copies of your database so you can develop, test, and dry-run safely.
### Why this matters
A test data source removes the worst class of mistakes — destructive operations that touch real customer records. It also speeds up iteration, because you can reset state freely and exercise edge cases without fear of corrupting production.
### What to check
* A dedicated test data source exists and is clearly distinguished from live (Xano lets you assign a color to each data source — use it)
* The data inside reflects the shape of production well enough to surface real problems
* Your tests, manual dry-runs, and any test frontend point at the test data source, not at live
### How to do it in Xano
Click your data source indicator in the status footer (e.g., "Live"), then **+ Add Data Source**. Name it descriptively (`Test`, `Staging`, `QA`) and assign a distinct color — Xano will surface that color throughout the UI so you can see at a glance which data source you're working against.
Choose the approach that matches what you're testing.
**Migrate from live** — use **Manage Data Sources → Migrate** to copy tables from live into your test source. Best when you need realistic shape and volume, and your live data isn't sensitive enough to require redaction. Watch out for personally identifiable information; consider migrating a subset or scrubbing fields before testing.
**Create sample data** — manually insert representative records. Best when live data is sensitive, doesn't exist yet, or doesn't cover the edge cases you want to test. Include the awkward shapes deliberately: empty strings, nulls, maximum lengths, very long arrays, unicode.
**Start empty** — use an empty data source when your tests are responsible for creating all the data they need (most workflow tests fit here). The benefit is reproducibility: every test run starts from the same known state.
For most teams, a combination works best — a migrated-and-scrubbed source for manual exploration, and an empty source that workflow tests populate themselves.
Click the data source indicator and select your test source. Run & Debug, unit tests, and workflow tests will now run against it.
Switching your data source in Xano only affects your development environment. Your live application keeps reading and writing to the live data source until you tell it otherwise.
Walk through real user journeys using Run & Debug, then run your unit and workflow test suites. Try destructive operations — bulk deletes, schema migrations, mass updates — that you'd never test against live data.
### Pointing a frontend at the test data source
If you have a staging or test build of your frontend, you can route its API traffic to the test data source without maintaining a second backend. Xano honors a data source override on every request:
* **Header (preferred for code)**: set `X-Data-Source: test` in your HTTP client's default headers. Every request from that build will read and write against the `test` data source.
* **Query string (preferred for ad-hoc checks)**: append `?x-data-source=test` to a URL. Useful for sharing a one-off test link or debugging in a browser.
Requests *without* the header or query parameter continue to hit your live data source. That means your production frontend doesn't need to change — only your test build does.
Replace `test` with whatever you named your test data source.
### What to look for
* Tests and dry-runs hit the test data source, not live (the color indicator in the UI is your fastest check)
* The test data source has enough variety to exercise the edge cases your code claims to handle
* A staging frontend, if you have one, sends the `X-Data-Source` header on every request
* Live frontend requests still have no override and continue to hit live
### Common issues to fix
* Forgetting to switch back — long sessions can drift between data sources without you noticing. The color indicator is there to prevent this; use it
* Stale test data that no longer matches the current schema after migrations — refresh or rebuild it
* Sensitive production data copied into a test source without scrubbing — treat test sources as having the same access controls as live until you've removed sensitive fields
* Workflow tests that depend on data that only exists in one developer's local test source — make tests set up their own data
### Before moving on
You should have a clearly-marked test data source, at least one way of populating it that matches your testing needs, and confidence that nothing you're doing during dry-runs can reach live data.
***
## Load testing
Load testing simulates concurrent users hitting your backend and tells you whether response times, error rates, and throughput hold up under realistic traffic. Xano does not include built-in load testing — you'll use an external tool.
### When load testing is necessary
You probably want to load test if any of these apply:
* A marketing launch, press placement, or campaign that could produce a traffic spike
* A public, unauthenticated endpoint (sign-ups, search, public APIs) that anyone can hit
* A partner integration that will send batched or sustained traffic
* A move between Scale tiers, especially upward — you want to confirm the new tier behaves as expected before you depend on it
* Recurring slow-response complaints that you can't reproduce with synthetic single-request tests
You probably don't need formal load testing for internal tools with predictable, low concurrency, or for early-stage workspaces where the traffic shape isn't known yet. In those cases, the performance baseline review earlier in this guide is usually enough.
### What to check
* Response times under realistic concurrency, not just single-request latency
* Error rates, including which status codes appear (429s and 5xx are particularly informative)
* Throughput — how many requests per second the backend sustains before degrading
* Whether degradation is graceful (response times rise) or abrupt (errors spike)
### How to do it in Xano
Common options:
* [Apache JMeter](https://jmeter.apache.org/) — open-source, highly configurable
* [Artillery](https://www.artillery.io/) — YAML-based, developer-friendly
* [k6](https://k6.io/) — JavaScript-based, scriptable
* [Loader.io](https://loader.io/) — cloud-based, low setup
* [BlazeMeter](https://www.blazemeter.com/) — enterprise, JMeter-compatible
Any of these will work with Xano endpoints. Pick the one your team can write and maintain scenarios in.
A useful load test reflects what users actually do, not raw RPS against one endpoint.
Decide:
* **Concurrent users** — how many simultaneous sessions you expect at peak
* **Request mix** — which endpoints get hit and in what ratio
* **Ramp-up** — how quickly traffic builds, not just the steady-state target
* **Duration** — long enough to surface issues that don't appear in the first thirty seconds (connection pool exhaustion, slow memory creep)
A representative scenario for an e-commerce backend: ramp from 10 to 1,000 concurrent users over 10 minutes, each user performing log in → browse products → add to cart → checkout.
Load testing against live traffic is rarely what you want. Use a test branch, staging workspace, or — on plans that allow it — a separate instance via [Xano Link](/xano-features/advanced-back-end-features/xano-link). Branching options are covered in [Branching & Merging](/team-collaboration/branching-and-merging).
Make sure the staging environment matches production as closely as possible — same Scale tier, same data shape, same external integrations or realistic mocks.
Open these in separate tabs and watch them live:
* **[Performance Insights](/maintenance-monitoring-and-logging/performance-insights)** — does p95 execution time stay flat as concurrency rises, or climb?
* **[Request History](/maintenance-monitoring-and-logging/request-history)** — what error codes appear, and on which endpoints? 429 responses indicate rate limiting; 5xx responses indicate something gave up
* **[Statement Explorer](/maintenance-monitoring-and-logging/statement-explorer)** — which database statements are slow under load, and are they the same ones that were slow at low load?
* **API and database node utilization** — available on higher-tier plans; tells you which side of the backend is saturating first
If response times degrade or errors spike, the earlier sections of this guide are where you fix it: optimize the slow paths Performance Insights surfaces, address any logic errors the test exposes, and adjust your Scale plan if you're hitting node-level limits. Then re-run the same scenario to confirm the change moved the numbers.
### What to look for
* Response times that stay within budget across the full ramp, not just at the start
* Error rates that stay low and don't climb sharply at peak concurrency
* Throughput that grows roughly linearly with concurrency until you reach the saturation point you expect
* No single endpoint absorbing a disproportionate share of latency or errors under load
### Common issues to fix
* A single slow endpoint dragging tail latency for everything — isolate and optimize it
* Connection-pool or external-dependency limits surfacing only at scale — adjust pool sizes or batch upstream calls
* Background tasks competing with synchronous request handlers for resources — separate them where you can
* Hitting Scale tier limits earlier than expected — review tier sizing before launch, not during
### Before moving on
You should know how much concurrency your backend handles cleanly, where it starts to degrade, and what happens at the edge of its capacity. If you've sized your Scale plan for expected peak with reasonable headroom, you're in good shape.
***
## How the layers fit together
Each layer in this guide validates a different question, and each one builds on the one below it. Working through them in order is what keeps issues cheap to fix.
| Layer | What it validates | Where issues surface |
| --------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------- |
| Performance baselines | How your backend behaves today, at current traffic | Slow queries, hot endpoints, expensive external calls |
| Unit tests | Individual function stacks return correct output for given input | Logic errors, regressions in a single endpoint |
| Workflow tests | Multi-step user journeys complete correctly end to end | Integration errors, broken state transitions, missing fields |
| Test data dry-run | The application behaves correctly against realistic, safe data | Schema mismatches, edge-case handling, destructive-operation safety |
| Load testing | The backend holds up under concurrent traffic | Scale-tier sizing, contention, degradation patterns |
The order matters. Fixing a logic bug is much cheaper at the unit-test layer than discovering it under load. Each layer is a filter that catches a different class of problem before the next layer would have to.
This flow also maps naturally onto a CI/CD setup — see [CI/CD](/ci-cd) for the broader pipeline view.
***
## Deployment readiness checklist
Work through this before pointing production traffic at the backend. Group the items by category so you can divide the work across a team.
**Performance**
* [ ] Reviewed [Performance Insights](/maintenance-monitoring-and-logging/performance-insights) over a representative window
* [ ] Identified the slowest endpoints and the busiest endpoints, and prioritized work where the two overlap
* [ ] Optimized or knowingly deferred each slow path
* [ ] Reviewed [Request History](/maintenance-monitoring-and-logging/request-history) for unexpected errors or large payloads
**Testing**
* [ ] [Unit tests](/testing-debugging/unit-tests) exist for the critical endpoints and functions you identified
* [ ] [Workflow tests](/testing-debugging/test-suites) cover the critical multi-step user journeys
* [ ] Failure branches are tested, not only happy paths
* [ ] External dependencies are mocked where they would otherwise make tests flaky
* [ ] The full suite runs end-to-end without surprise failures
**Data safety**
* [ ] A dedicated test [data source](/the-database/database-basics/data-sources) exists, distinct from live and visually distinguished
* [ ] Test data reflects realistic shapes and includes the edge cases your code claims to handle
* [ ] Sensitive fields copied from live have been scrubbed or excluded
* [ ] Any staging frontend points at the test data source via `X-Data-Source`, and production traffic still hits live
**Release process**
* [ ] A [branching strategy](/team-collaboration/branching-and-merging) is in place for ongoing deployments
* [ ] Drafted work intended for launch has been published
* [ ] [OpenAPI documentation](/the-function-stack/building-with-visual-development/apis/swagger-openapi-documentation) is reviewed and accurate
* [ ] The [Pre-Launch Security Checklist](/security/pre-launch-security-checklist) has been completed
**Scale**
* [ ] Expected peak traffic is documented
* [ ] Your Scale plan is sized for that peak with reasonable headroom
* [ ] If a traffic spike is expected at launch, load testing has been performed against staging
* [ ] You've decided how you'll monitor production after launch ([Performance Insights](/maintenance-monitoring-and-logging/performance-insights), [Request History](/maintenance-monitoring-and-logging/request-history), [Statement Explorer](/maintenance-monitoring-and-logging/statement-explorer))
***
## Common deployment readiness mistakes
* **Testing only happy paths.** Production traffic exercises the error branches too. Cover invalid inputs, missing fields, expired tokens, and denied permissions explicitly.
* **Treating workflow tests as a replacement for unit tests.** Workflow tests are slow and hard to debug when they fail; unit tests are where you isolate logic. You need both.
* **Running tests or dry-runs against live data.** Even read-only flows can produce surprising writes through triggers or related endpoints. Switch to a test data source.
* **Aiming for a coverage number rather than coverage of what matters.** High coverage on trivial functions while critical paths are untested looks reassuring but isn't.
* **Skipping load testing because traffic is small today.** A baseline test now tells you where the saturation point is *before* you depend on knowing it. Small now and large at launch is exactly when you want the data.
* **Forgetting that schema changes invalidate prior test results.** After any schema migration, re-run the suite — assumptions about field shapes may no longer hold.
* **Treating deployment readiness as separate from security readiness.** A backend can be fast, well-tested, and still expose endpoints it shouldn't. Work through the [Pre-Launch Security Checklist](/security/pre-launch-security-checklist) alongside this one.
* **Letting flaky tests stay in the suite.** Tests that pass on retry train the team to ignore failures. Fix them, quarantine them, or remove them — don't tolerate them.
***
## Next steps
Once you've worked through this guide:
1. **Publish drafted changes** so your live environment reflects the version you've validated.
2. **Confirm your branching strategy** for ongoing work — see [Branching & Merging](/team-collaboration/branching-and-merging).
3. **Connect your frontend** following the [Connecting to a Frontend](/connecting-to-a-frontend) guide, and verify that production traffic routes to live (not test) by default.
4. **Set up ongoing monitoring** with [Request History](/maintenance-monitoring-and-logging/request-history) and [Performance Insights](/maintenance-monitoring-and-logging/performance-insights), and decide what changes in those views would prompt you to investigate.
5. **Re-run this checklist** before significant releases. Deployment readiness is a practice, not a one-time event.
# Developer API (Deprecated)
Source: https://docs.xano.com/developer-api-deprecated
The Developer API is deprecated. Please see the [Metadata API (beta)](/xano-features/metadata-api) for the newest solution.
The Xano Developer API allows you to interact with your account in an automated fashion.
The primary use case is the ability to authenticate and then retrieve Swagger/OpenAPI documentation for each of your API groups on each of your Xano instances. More functionality will be coming soon.
Since Xano supports a single tenant infrastructure on each of its premium instances, it is important to understand that different authentication is required for different aspects of this API.
Authentication starts with your Developer API Key, which allows you to authenticate your account with the master service. This master service is responsible for managing your account, subscriptions, and instances.
By listing each instance you have access to, you will then be able to re-authenticate with each individual instance to view the Developer API for that instance. Then you will have access to list workspaces and the API groups within each workspace, which then gives you access to the appropriate Swagger documentation for each API group.
### Step 1: Generate your Developer API Key
This is available on the Account page. Every account has the ability to have a single Developer API Key. **Once this is generated, it is no longer possible to view the key**, so it is very important to write this down in a safe place, so it isn't forgotten. If it is forgotten, then you need to revoke the current one and generate a new key.
### Step 2: Xano Master Service Documentation
Now that you have your API Key, you can start authenticating against the API endpoints for the Xano master service. The API documentation is detailed at [https://app.xano.com/api:developer](https://app.xano.com/api:developer).
Currently, there is only support to list your Xano instances, but more functionality will be fleshed out over the next several releases.
Authentication is handled using the Authorization HTTP header along with the Bearer token specification.
If you are viewing the Swagger documentation, then you can click the "Authorize" button and paste in your Developer API key. Then you can click on the Instances endpoint and click the "Try Out" button to execute the API endpoint.
If you are using the API directly via your front-end or the CURL command line utility, then you would need to include your Developer API key as follows.
In the CURL example below you would replace the text YOUR\_DEVELOPER\_API\_KEY with your actual Developer API Key.
```powershell theme={null}
curl -X 'GET' \
'https://app.xano.com/api:developer/instance' \
-H 'accept: application/json' \
-H 'Authorization: Bearer YOUR_DEVELOPER_API_KEY'
```
The following would be an example response to expect, if your account had access to two instances.
```json theme={null}
[
{
"id": 1,
"name": "explore-instance",
"display": "Explore Instance",
"description": "",
"host": "",
"tokenUrl": "https://app.xano.com/api:developer/token/auth?token=DBWJQ2..."
},
{
"id": 2,
"name": "starter-instance",
"display": "Starter Instance",
"description": "",
"host": "",
"tokenUrl": "https://app.xano.com/api:developer/token/auth?token=6B67wcN..."
}
]
```
### Step 3: Fetch the tokenUrl for your instance
The tokenUrl for each instance has an authenticated token parameter to give you access to the Authorization token required to call the API for that specific instance.
In the above example, if we fetch the tokenUrl, then the following example response would be expected.
```json theme={null}
{
"authToken": "eyJhbGciOiJBMjU2S1ciLCJlbmMiOiJ...",
"api": "https://x8d0-doy0-xx99.n0.xano.io/api:developer",
"swaggerspec": "https://x8d0-doy0-xx99.n0.xano.io/apispec:developer?type=json",
"origin": "https://x8d0-doy0-xx99.n0.xano.io"
}
```
The authToken key will be used to authenticate to any endpoints listed within the API or swaggerspec links.
**The API key** is a link to the Swagger documentation for the Developer APIs for this specific instance.
**The swaggerspec key** is a link to the json spec for the Swagger documentation in case you want to programmatically parse the endpoints available within the documentation.
**The origin key** is useful for knowing the desired http origin of any requests sent to the instance. This is normally Xano URL, but can change if a custom domain is enabled.
### Step 4: Call the APIs of your Instance
Now that we have the authToken from Step 3, we can call the endpoints available within the API link above.
Any endpoints within this instance that require authentication, must use this authToken and not your API Developer Key. The API Developer Key is only intended for the Xano master service.
```powershell theme={null}
curl -X 'GET' \
'https://x8d0-doy0-xx99.n0.xano.io/api:developer/workspace' \
-H 'accept: application/json' \
-H 'Authorization: Bearer eyJhbGciOiJBMjU2S1ciLCJlbmMiOiJ...'
```
Below is an example response to the workspace endpoint listed above.
```json theme={null}
[
{
"id": 2,
"name": "Book Marketplace",
"description": "This is an example workspace.",
"apigroups": [
{
"id": 4,
"name": "Public API",
"description": "",
"api": "https://x8d0-doy0-xx99.n0.xano.io/api:Wk_siXX",
"swaggerspec": "https://x8d0-doy0-xx99.n0.xano.io/apispec:Wk_siXX"
},
{
"id": 5,
"name": "Private API",
"description": "",
"api": "https://xb17-541e-40b9.dev.xano.io/api:YkBUXX",
"swaggerspec": "https://xb17-541e-40b9.dev.xano.io/apispec:YkBUXX"
}
]
}
]
```
From this response, you can see there is one workspace with two API Groups. Each API Group has its own api and swaggerspec key. The difference here is that these APIs are the ones built by you in your own instance. This also means that these will require their own Authentication.
# Claude Code
Source: https://docs.xano.com/developer-mcp/clients/claude-code
Install and use the Xano Developer MCP with Claude Code
## Prerequisites
* [Node.js](https://nodejs.org/) 18 or later
* [Claude Code](https://claude.com/claude-code) installed and authenticated
## Installation
### Install the MCP Server
Run the following command in your terminal:
```bash theme={null}
claude mcp add xano -- npx -y @xano/developer-mcp
```
This registers `xano` as an MCP server for Claude Code. To make the server available across every project instead of the current directory, add `--scope user`:
```bash theme={null}
claude mcp add --scope user xano -- npx -y @xano/developer-mcp
```
Restart any active Claude Code sessions so the new server is picked up.
### Verify Setup
In Claude Code, ask:
> "What version of the Xano Developer MCP is installed?"
Claude Code should call `mcp_version` and return the current version number.
## Usage
The Developer MCP lets Claude Code write and validate XanoScript using your local Xano workspace as context.
Before asking Claude Code to make changes, pull a workspace locally with the Xano CLI. If you haven't installed and authenticated with the CLI yet, [do that now](/xano-cli/get-started) before continuing. Then select or create a workspace and run:
```bash theme={null}
xano workspace pull
```
Once your workspace is available locally, you can ask Claude Code to help with XanoScript tasks, from building a complete workspace:
```bash theme={null}
Create a small backend for advisor client intake. It should include a `clients` table with fields for name, email, phone, risk tolerance, investment objective, and advisor notes. Add API endpoints to create a client, list clients, get a single client by ID, and update client details. Include validation for required fields and valid risk tolerance values.
```
Claude Code creates a small advisor client intake backend for storing and managing client profile details.
The generated backend includes a `clients` table with fields for the client's name, email, phone number, risk tolerance, investment objective, advisor notes, and timestamps. The email field is stored as a unique value, so duplicate client records cannot be created with the same email address.
It also adds a `clients` API group with endpoints to:
* Create a new client
* List clients with pagination and sorting
* Get a single client by ID
* Update an existing client
The generated XanoScript includes validation for required fields, supported risk tolerance values, duplicate email addresses, and missing client records. Before pushing the changes, Claude Code validates the generated XanoScript with the Developer MCP and fixes any issues it finds.
You can [download the complete backend](/files/advisor-client-backend.zip) for further review.
You can also ask it to expand or iterate on existing backends.
```bash theme={null}
Add a follow-up task feature to the advisor client intake backend. Create a `client_tasks` table linked to clients, with fields for task title, due date, status, and notes. Add API endpoints to create a task for a client, list all tasks for a client, and mark a task as complete.
```
Claude Code extends the advisor client intake backend with a follow-up task feature for managing next steps after a client profile is created.
The updated backend keeps the existing `clients` table and API endpoints for creating, listing, retrieving, and updating client records. It also adds a new `client_tasks` table linked to the `clients` table, so each task belongs to a specific client.
The `client_tasks` table includes fields for the related client, task title, due date, status, notes, and timestamps. Task status supports values like `pending`, `in_progress`, and `completed`, making it possible to track where each follow-up task stands.
The backend also adds new API endpoints to:
* Create a follow-up task for a client
* List all follow-up tasks for a client
* Mark a follow-up task as complete
The generated XanoScript includes checks for missing clients, missing task titles, valid task statuses, and missing task records. Before pushing the changes, Claude Code validates the updated XanoScript with the Developer MCP and fixes any issues it finds.
Once you're ready, push the changes to your sandbox so you can review them in the browser before promoting to your live workspace:
```bash theme={null}
xano sandbox push -d ./my-workspace
xano sandbox review
```
`xano sandbox review` opens your sandbox in the browser — verify everything looks right, then promote the changes to production from there.
## What's Next
Explore all 6 tools available in the Developer MCP
Access MCP resources and use the package as an npm library
# Claude Desktop
Source: https://docs.xano.com/developer-mcp/clients/claude-desktop
Install and use the Xano Developer MCP with Claude Desktop
## Prerequisites
* [Node.js](https://nodejs.org/) 18 or later
* [Claude Desktop](https://claude.com/download) installed
## Installation
### Install the MCP Server
Add the Xano Developer MCP to your Claude Desktop configuration file.
Edit `~/Library/Application Support/Claude/claude_desktop_config.json`:
Edit `%APPDATA%\Claude\claude_desktop_config.json`:
```json theme={null}
{
"mcpServers": {
"xano": {
"command": "npx",
"args": ["-y", "@xano/developer-mcp"]
}
}
}
```
Save the file and **fully quit and restart Claude Desktop** so the new server is loaded. Reopening the window is not enough.
### Verify Setup
In Claude Desktop, ask:
> "What version of the Xano Developer MCP is installed?"
Claude should call `mcp_version` and return the current version number.
## Usage
The Developer MCP gives Claude Desktop access to XanoScript documentation, code validation, and CLI/API references. Because Claude Desktop is a chat surface (not a code editor), it's best suited for asking questions, drafting XanoScript snippets, and validating code you paste into the chat.
For example:
```bash theme={null}
Validate this XanoScript and fix any issues:
query users { return db.user.list({}) }
```
Claude calls the `validate_xanoscript` tool, finds the syntax error in the snippet, and rewrites it correctly. The corrected version is returned in the chat for you to copy back into your editor or workspace.
You can also ask it conceptual questions like:
```bash theme={null}
What's the difference between a XanoScript function and a query? When should I use each?
```
For full project-building workflows where the AI writes files directly into your workspace, use [Claude Code](/developer-mcp/clients/claude-code) or [VS Code with Claude Code](/developer-mcp/clients/vs-code-claude-code) instead.
## What's Next
Explore all 6 tools available in the Developer MCP
Access MCP resources and use the package as an npm library
# Codex
Source: https://docs.xano.com/developer-mcp/clients/codex
Install and use the Xano Developer MCP with OpenAI Codex
## Prerequisites
* [Node.js](https://nodejs.org/) 18 or later
* [Codex](https://github.com/openai/codex) installed
If you don't have Codex yet:
```bash theme={null}
npm install -g @openai/codex
```
## Installation
### Install the MCP Server
Add the Xano Developer MCP to Codex:
```bash theme={null}
codex mcp add xano -- npx -y @xano/developer-mcp
```
Restart any active Codex sessions so the new server is picked up.
### Verify Setup
In Codex, ask:
> "What version of the Xano Developer MCP is installed?"
Codex should call `mcp_version` and return the current version number.
## Usage
The Developer MCP lets Codex write and validate XanoScript using your local Xano workspace as context.
Before asking Codex to make changes, pull a workspace locally with the Xano CLI. If you haven't installed and authenticated with the CLI yet, [do that now](/xano-cli/get-started) before continuing. Then select or create a workspace and run:
```bash theme={null}
xano workspace pull
```
Once your workspace is available locally, you can ask Codex to help with XanoScript tasks, from building a complete workspace:
```bash theme={null}
Create a small backend for advisor client intake. It should include a `clients` table with fields for name, email, phone, risk tolerance, investment objective, and advisor notes. Add API endpoints to create a client, list clients, get a single client by ID, and update client details. Include validation for required fields and valid risk tolerance values.
```
Codex creates a small advisor client intake backend for storing and managing client profile details.
The generated backend includes a `clients` table with fields for the client's name, email, phone number, risk tolerance, investment objective, advisor notes, and timestamps. The email field is stored as a unique value, so duplicate client records cannot be created with the same email address.
It also adds a `clients` API group with endpoints to:
* Create a new client
* List clients with pagination and sorting
* Get a single client by ID
* Update an existing client
The generated XanoScript includes validation for required fields, supported risk tolerance values, duplicate email addresses, and missing client records. Before pushing the changes, Codex validates the generated XanoScript with the Developer MCP and fixes any issues it finds.
You can [download the complete backend](/files/advisor-client-backend.zip) for further review.
You can also ask it to expand or iterate on existing backends.
```bash theme={null}
Add a follow-up task feature to the advisor client intake backend. Create a `client_tasks` table linked to clients, with fields for task title, due date, status, and notes. Add API endpoints to create a task for a client, list all tasks for a client, and mark a task as complete.
```
Codex extends the advisor client intake backend with a follow-up task feature for managing next steps after a client profile is created.
The updated backend keeps the existing `clients` table and API endpoints for creating, listing, retrieving, and updating client records. It also adds a new `client_tasks` table linked to the `clients` table, so each task belongs to a specific client.
The `client_tasks` table includes fields for the related client, task title, due date, status, notes, and timestamps. Task status supports values like `pending`, `in_progress`, and `completed`, making it possible to track where each follow-up task stands.
The backend also adds new API endpoints to:
* Create a follow-up task for a client
* List all follow-up tasks for a client
* Mark a follow-up task as complete
The generated XanoScript includes checks for missing clients, missing task titles, valid task statuses, and missing task records. Before pushing the changes, Codex validates the updated XanoScript with the Developer MCP and fixes any issues it finds.
Once you're ready, push the changes to your sandbox so you can review them in the browser before promoting to your live workspace:
```bash theme={null}
xano sandbox push -d ./my-workspace
xano sandbox review
```
`xano sandbox review` opens your sandbox in the browser — verify everything looks right, then promote the changes to production from there.
## What's Next
Explore all 6 tools available in the Developer MCP
Access MCP resources and use the package as an npm library
# Cursor
Source: https://docs.xano.com/developer-mcp/clients/cursor
Install and use the Xano Developer MCP with Cursor
## Prerequisites
* [Node.js](https://nodejs.org/) 18 or later
* [Cursor](https://cursor.com/) installed
## Installation
### Install the MCP Server
**One-click Install:**
**Manual Installation:**
Open **Cursor Settings → Tools & MCPs**, click **Add MCP Server**, and add:
```json theme={null}
{
"xano": {
"command": "npx",
"args": ["-y", "@xano/developer-mcp"]
}
}
```
Save the configuration and restart Cursor so the new server is registered.
### Verify Setup
In Cursor's chat panel, ask:
> "What version of the Xano Developer MCP is installed?"
Cursor should call `mcp_version` and return the current version number.
### Install the XanoScript Language Server extension
The language server extension enables code completion and syntax highlighting for XanoScript, and is essential for the best experience. Cursor uses the same extension marketplace as VS Code, so you can install it [here](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript-language-server).

## Usage
The Developer MCP lets Cursor write and validate XanoScript using your local Xano workspace as context.
Before asking Cursor to make changes, pull a workspace locally with the Xano CLI. If you haven't installed and authenticated with the CLI yet, [do that now](/xano-cli/get-started) before continuing. Then select or create a workspace and run:
```bash theme={null}
xano workspace pull
```
Once your workspace is available locally, you can ask Cursor to help with XanoScript tasks, from building a complete workspace:
```bash theme={null}
Create a small backend for advisor client intake. It should include a `clients` table with fields for name, email, phone, risk tolerance, investment objective, and advisor notes. Add API endpoints to create a client, list clients, get a single client by ID, and update client details. Include validation for required fields and valid risk tolerance values.
```
Cursor creates a small advisor client intake backend for storing and managing client profile details.
The generated backend includes a `clients` table with fields for the client's name, email, phone number, risk tolerance, investment objective, advisor notes, and timestamps. The email field is stored as a unique value, so duplicate client records cannot be created with the same email address.
It also adds a `clients` API group with endpoints to:
* Create a new client
* List clients with pagination and sorting
* Get a single client by ID
* Update an existing client
The generated XanoScript includes validation for required fields, supported risk tolerance values, duplicate email addresses, and missing client records. Before pushing the changes, Cursor validates the generated XanoScript with the Developer MCP and the XanoScript Language Server, and fixes any issues it finds.
You can [download the complete backend](/files/advisor-client-backend.zip) for further review.
You can also ask it to expand or iterate on existing backends.
```bash theme={null}
Add a follow-up task feature to the advisor client intake backend. Create a `client_tasks` table linked to clients, with fields for task title, due date, status, and notes. Add API endpoints to create a task for a client, list all tasks for a client, and mark a task as complete.
```
Cursor extends the advisor client intake backend with a follow-up task feature for managing next steps after a client profile is created.
The updated backend keeps the existing `clients` table and API endpoints for creating, listing, retrieving, and updating client records. It also adds a new `client_tasks` table linked to the `clients` table, so each task belongs to a specific client.
The `client_tasks` table includes fields for the related client, task title, due date, status, notes, and timestamps. Task status supports values like `pending`, `in_progress`, and `completed`, making it possible to track where each follow-up task stands.
The backend also adds new API endpoints to:
* Create a follow-up task for a client
* List all follow-up tasks for a client
* Mark a follow-up task as complete
The generated XanoScript includes checks for missing clients, missing task titles, valid task statuses, and missing task records. Before pushing the changes, Cursor validates the updated XanoScript with the Developer MCP and fixes any issues it finds.
Once you're ready, push the changes to your sandbox so you can review them in the browser before promoting to your live workspace:
```bash theme={null}
xano sandbox push -d ./my-workspace
xano sandbox review
```
`xano sandbox review` opens your sandbox in the browser — verify everything looks right, then promote the changes to production from there.
## What's Next
Explore all 6 tools available in the Developer MCP
Access MCP resources and use the package as an npm library
# Gemini CLI
Source: https://docs.xano.com/developer-mcp/clients/gemini-cli
Install and use the Xano Developer MCP with Gemini CLI
## Prerequisites
* [Node.js](https://nodejs.org/) 18 or later
* [Gemini CLI](https://github.com/google-gemini/gemini-cli) installed and authenticated
## Installation
### Install the MCP Server
Add the Xano Developer MCP to your Gemini CLI settings file at `~/.gemini/settings.json`:
```json theme={null}
{
"mcpServers": {
"xano": {
"command": "npx",
"args": ["-y", "@xano/developer-mcp"]
}
}
}
```
To scope the server to a single project instead of all projects, put the same `mcpServers` block in `.gemini/settings.json` at your project root.
Restart any active Gemini CLI sessions so the new server is picked up.
### Verify Setup
In Gemini CLI, ask:
> "What version of the Xano Developer MCP is installed?"
Gemini should call `mcp_version` and return the current version number.
## Usage
The Developer MCP lets Gemini CLI write and validate XanoScript using your local Xano workspace as context.
Before asking Gemini to make changes, pull a workspace locally with the Xano CLI. If you haven't installed and authenticated with the CLI yet, [do that now](/xano-cli/get-started) before continuing. Then select or create a workspace and run:
```bash theme={null}
xano workspace pull
```
Once your workspace is available locally, you can ask Gemini to help with XanoScript tasks, from building a complete workspace:
```bash theme={null}
Create a small backend for advisor client intake. It should include a `clients` table with fields for name, email, phone, risk tolerance, investment objective, and advisor notes. Add API endpoints to create a client, list clients, get a single client by ID, and update client details. Include validation for required fields and valid risk tolerance values.
```
Gemini creates a small advisor client intake backend for storing and managing client profile details.
The generated backend includes a `clients` table with fields for the client's name, email, phone number, risk tolerance, investment objective, advisor notes, and timestamps. The email field is stored as a unique value, so duplicate client records cannot be created with the same email address.
It also adds a `clients` API group with endpoints to:
* Create a new client
* List clients with pagination and sorting
* Get a single client by ID
* Update an existing client
The generated XanoScript includes validation for required fields, supported risk tolerance values, duplicate email addresses, and missing client records. Before pushing the changes, Gemini validates the generated XanoScript with the Developer MCP and fixes any issues it finds.
You can [download the complete backend](/files/advisor-client-backend.zip) for further review.
You can also ask it to expand or iterate on existing backends.
```bash theme={null}
Add a follow-up task feature to the advisor client intake backend. Create a `client_tasks` table linked to clients, with fields for task title, due date, status, and notes. Add API endpoints to create a task for a client, list all tasks for a client, and mark a task as complete.
```
Gemini extends the advisor client intake backend with a follow-up task feature for managing next steps after a client profile is created.
The updated backend keeps the existing `clients` table and API endpoints for creating, listing, retrieving, and updating client records. It also adds a new `client_tasks` table linked to the `clients` table, so each task belongs to a specific client.
The `client_tasks` table includes fields for the related client, task title, due date, status, notes, and timestamps. Task status supports values like `pending`, `in_progress`, and `completed`, making it possible to track where each follow-up task stands.
The backend also adds new API endpoints to:
* Create a follow-up task for a client
* List all follow-up tasks for a client
* Mark a follow-up task as complete
The generated XanoScript includes checks for missing clients, missing task titles, valid task statuses, and missing task records. Before pushing the changes, Gemini validates the updated XanoScript with the Developer MCP and fixes any issues it finds.
Once you're ready, push the changes to your sandbox so you can review them in the browser before promoting to your live workspace:
```bash theme={null}
xano sandbox push -d ./my-workspace
xano sandbox review
```
`xano sandbox review` opens your sandbox in the browser — verify everything looks right, then promote the changes to production from there.
## What's Next
Explore all 6 tools available in the Developer MCP
Access MCP resources and use the package as an npm library
# VS Code + AI
Source: https://docs.xano.com/developer-mcp/clients/vs-code
Install the Xano Developer MCP in VS Code with GitHub Copilot or any AI CLI agent
This page covers using the Xano Developer MCP inside VS Code. The primary path is **GitHub Copilot**, since it's the AI assistant built into VS Code itself. Other AI CLI agents (Claude Code, Codex, Gemini CLI) work just as well from VS Code's integrated terminal — quick-setup instructions for each are at the bottom of the page.
## Prerequisites
* [Node.js](https://nodejs.org/) 18 or later
* [VS Code](https://code.visualstudio.com/) with the [GitHub Copilot](https://marketplace.visualstudio.com/items?itemName=GitHub.copilot) and [GitHub Copilot Chat](https://marketplace.visualstudio.com/items?itemName=GitHub.copilot-chat) extensions installed
* An active GitHub Copilot subscription
## Installation
### 1. Install the MCP Server
**Method 1: Click to install**
**Method 2: Manual install**
1. Open the Command Palette by pressing ⌘ / Ctrl + P and type MCP. Click **MCP: Add Server**
2. Choose **Command (stdio)** and provide the command `npx -y @xano/developer-mcp`
3. Give the server a name, such as *Xano Developer MCP*
4. Choose whether to enable the MCP in the open workspace only, or for the entire profile
### 2. Install the XanoScript Language Server extension
The Language Server extension is required for the best AI-assisted XanoScript experience — it provides code completion, syntax highlighting, and inline diagnostics that every AI tool on this page (Copilot, Claude Code, Codex, Gemini CLI) reads from.
Install it from the [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript-language-server).

### 3. Verify Setup
In Copilot Chat, ask:
> "What version of the Xano Developer MCP is installed?"
Copilot should call `mcp_version` and return the current version number.
## Using Copilot
The Developer MCP lets Copilot write and validate XanoScript using your local Xano workspace as context.
Before asking Copilot to make changes, pull a workspace locally with the Xano CLI. If you haven't installed and authenticated with the CLI yet, [do that now](/xano-cli/get-started) before continuing. Then select or create a workspace and run:
```bash theme={null}
xano workspace pull
```
Once your workspace is available locally, you can ask Copilot to help with XanoScript tasks, from building a complete workspace:
```bash theme={null}
Create a small backend for advisor client intake. It should include a `clients` table with fields for name, email, phone, risk tolerance, investment objective, and advisor notes. Add API endpoints to create a client, list clients, get a single client by ID, and update client details. Include validation for required fields and valid risk tolerance values.
```
Copilot creates a small advisor client intake backend for storing and managing client profile details.
The generated backend includes a `clients` table with fields for the client's name, email, phone number, risk tolerance, investment objective, advisor notes, and timestamps. The email field is stored as a unique value, so duplicate client records cannot be created with the same email address.
It also adds a `clients` API group with endpoints to:
* Create a new client
* List clients with pagination and sorting
* Get a single client by ID
* Update an existing client
The generated XanoScript includes validation for required fields, supported risk tolerance values, duplicate email addresses, and missing client records. Before pushing the changes, Copilot validates the generated XanoScript with the Developer MCP and the XanoScript Language Server, and fixes any issues it finds.
You can also ask it to expand or iterate on existing backends.
```bash theme={null}
Add a follow-up task feature to the advisor client intake backend. Create a `client_tasks` table linked to clients, with fields for task title, due date, status, and notes. Add API endpoints to create a task for a client, list all tasks for a client, and mark a task as complete.
```
Copilot extends the advisor client intake backend with a follow-up task feature for managing next steps after a client profile is created.
The updated backend keeps the existing `clients` table and API endpoints for creating, listing, retrieving, and updating client records. It also adds a new `client_tasks` table linked to the `clients` table, so each task belongs to a specific client.
The `client_tasks` table includes fields for the related client, task title, due date, status, notes, and timestamps. Task status supports values like `pending`, `in_progress`, and `completed`, making it possible to track where each follow-up task stands.
The backend also adds new API endpoints to:
* Create a follow-up task for a client
* List all follow-up tasks for a client
* Mark a follow-up task as complete
The generated XanoScript includes checks for missing clients, missing task titles, valid task statuses, and missing task records. Before pushing the changes, Copilot validates the updated XanoScript with the Developer MCP and fixes any issues it finds.
Check out the [full example backend](https://github.com/xano-community/client-intake) on Github.
Once you're ready, push the changes to your sandbox so you can review them in the browser before promoting to your live workspace:
```bash theme={null}
xano sandbox push -d ./my-workspace
xano sandbox review
```
`xano sandbox review` opens your sandbox in the browser — verify everything looks right, then promote the changes to production from there.
***
## Using Claude Code, Gemini, Codex, or another CLI
Prefer a CLI agent over Copilot? Each of these runs in VS Code's integrated terminal (`View → Terminal`). Setup is identical to the standalone install — the sections below cover the quick install plus VS Code-specific quirks. Full guides for each agent are linked at the end of every section.
Install the [XanoScript Language Server extension](#2-install-the-xanoscript-language-server-extension) (Step 2 above) before continuing. Every CLI agent on this page depends on it for inline syntax help and diagnostics — don't skip it.
### Claude Code
In the integrated terminal:
```bash theme={null}
claude mcp add xano -- npx -y @xano/developer-mcp
```
Add `--scope user` to make the server available across every project rather than just the open workspace.
→ Full guide: [Claude Code](/developer-mcp/clients/claude-code)
### Codex
Install Codex if you don't already have it, then add the MCP — both run in the integrated terminal:
```bash theme={null}
npm install -g @openai/codex
codex mcp add xano -- npx -y @xano/developer-mcp
```
→ Full guide: [Codex](/developer-mcp/clients/codex)
### Gemini CLI
Edit `~/.gemini/settings.json` (user-wide) or `.gemini/settings.json` at the workspace root (project-only) and add:
```json theme={null}
{
"mcpServers": {
"xano": {
"command": "npx",
"args": ["-y", "@xano/developer-mcp"]
}
}
}
```
Then start `gemini` from the integrated terminal.
→ Full guide: [Gemini CLI](/developer-mcp/clients/gemini-cli)
***
## FAQ & Troubleshooting
Make sure you installed the [XanoScript Language Server](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript-language-server) extension. It applies to every AI tool on this page.
Confirm the `xano` MCP server is registered and connected:
* **Copilot:** check the MCP servers list in VS Code's settings.
* **Claude Code:** run `/mcp` inside a session, or `claude mcp list` in the terminal.
* **Codex:** run `codex mcp list`.
* **Gemini CLI:** run `/mcp` inside a session.
If the server isn't registered, re-run the install step. If it is registered but disconnected, restart the session — newly added servers don't take effect until a fresh start.
1. Did you install the Language Server extension?
2. Did you authenticate with the CLI and pull a workspace (even a new, blank workspace)?
Each tool scopes differently:
* **Copilot:** during MCP install, choose the profile-wide option instead of workspace-only.
* **Claude Code:** add `--scope user` to the install command.
* **Codex:** the `codex mcp add` command registers the server user-wide by default.
* **Gemini CLI:** put the `mcpServers` block in `~/.gemini/settings.json` rather than `.gemini/settings.json` at the project root.
***
## What's Next
Explore all 6 tools available in the Developer MCP
Access MCP resources and use the package as an npm library
# Windsurf
Source: https://docs.xano.com/developer-mcp/clients/windsurf
Install and use the Xano Developer MCP with Windsurf
## Prerequisites
* [Node.js](https://nodejs.org/) 18 or later
* [Windsurf](https://windsurf.com/) installed
## Installation
### Install the MCP Server
Open **Windsurf Settings → Cascade → MCP Servers** (or click the settings icon in the top right of the Cascade panel). From there, you'll need to edit the underlying config file at `~/.codeium/windsurf/mcp_config.json` directly:
```json theme={null}
{
"mcpServers": {
"xano": {
"command": "npx",
"args": ["-y", "@xano/developer-mcp"]
}
}
}
```
Save the configuration and restart Windsurf so the new server is registered.
### Verify Setup
In the Cascade panel, ask:
> "What version of the Xano Developer MCP is installed?"
Windsurf should call `mcp_version` and return the current version number.
### Install the XanoScript Language Server extension
The language server extension enables code completion and syntax highlighting for XanoScript, and is essential for the best experience. Windsurf uses the Open VSX extension registry — you can install the language server [here](https://open-vsx.org/extension/xano/xanoscript-language-server) (or via the VS Code Marketplace [here](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript-language-server) if Windsurf is configured to use it).

## Usage
The Developer MCP lets Windsurf write and validate XanoScript using your local Xano workspace as context.
Before asking Windsurf to make changes, pull a workspace locally with the Xano CLI. If you haven't installed and authenticated with the CLI yet, [do that now](/xano-cli/get-started) before continuing. Then select or create a workspace and run:
```bash theme={null}
xano workspace pull
```
Once your workspace is available locally, you can ask Windsurf to help with XanoScript tasks, from building a complete workspace:
```bash theme={null}
Create a small backend for advisor client intake. It should include a `clients` table with fields for name, email, phone, risk tolerance, investment objective, and advisor notes. Add API endpoints to create a client, list clients, get a single client by ID, and update client details. Include validation for required fields and valid risk tolerance values.
```
Windsurf creates a small advisor client intake backend for storing and managing client profile details.
The generated backend includes a `clients` table with fields for the client's name, email, phone number, risk tolerance, investment objective, advisor notes, and timestamps. The email field is stored as a unique value, so duplicate client records cannot be created with the same email address.
It also adds a `clients` API group with endpoints to:
* Create a new client
* List clients with pagination and sorting
* Get a single client by ID
* Update an existing client
The generated XanoScript includes validation for required fields, supported risk tolerance values, duplicate email addresses, and missing client records. Before pushing the changes, Windsurf validates the generated XanoScript with the Developer MCP and the XanoScript Language Server, and fixes any issues it finds.
You can [download the complete backend](/files/advisor-client-backend.zip) for further review.
You can also ask it to expand or iterate on existing backends.
```bash theme={null}
Add a follow-up task feature to the advisor client intake backend. Create a `client_tasks` table linked to clients, with fields for task title, due date, status, and notes. Add API endpoints to create a task for a client, list all tasks for a client, and mark a task as complete.
```
Windsurf extends the advisor client intake backend with a follow-up task feature for managing next steps after a client profile is created.
The updated backend keeps the existing `clients` table and API endpoints for creating, listing, retrieving, and updating client records. It also adds a new `client_tasks` table linked to the `clients` table, so each task belongs to a specific client.
The `client_tasks` table includes fields for the related client, task title, due date, status, notes, and timestamps. Task status supports values like `pending`, `in_progress`, and `completed`, making it possible to track where each follow-up task stands.
The backend also adds new API endpoints to:
* Create a follow-up task for a client
* List all follow-up tasks for a client
* Mark a follow-up task as complete
The generated XanoScript includes checks for missing clients, missing task titles, valid task statuses, and missing task records. Before pushing the changes, Windsurf validates the updated XanoScript with the Developer MCP and fixes any issues it finds.
Once you're ready, push the changes to your sandbox so you can review them in the browser before promoting to your live workspace:
```bash theme={null}
xano sandbox push -d ./my-workspace
xano sandbox review
```
`xano sandbox review` opens your sandbox in the browser — verify everything looks right, then promote the changes to production from there.
## What's Next
Explore all 6 tools available in the Developer MCP
Access MCP resources and use the package as an npm library
# Developer MCP
Source: https://docs.xano.com/developer-mcp/get-started
Install and configure the Xano Developer MCP for AI-assisted XanoScript development
The Xano Developer MCP (`@xano/developer-mcp`) is an MCP server that gives AI assistants superpowers for developing on Xano. It provides XanoScript documentation, code validation, and workflow guides directly to your AI tools.
**What does it do?**
The Developer MCP is designed for **building with Xano**, not managing your Xano instance. It helps AI assistants:
* Access XanoScript language documentation and syntax references
* Validate XanoScript code for syntax errors in real-time
* Retrieve Meta API, Run API, and CLI documentation on demand
* Provide context-aware docs based on the file you're editing
***
## Pick Your Client
The Developer MCP requires [Node.js](https://nodejs.org/) 18 or later. Choose your AI client below for installation and usage instructions.
Don't see your client? The Developer MCP works with any [MCP-compatible client](https://modelcontextprotocol.io/clients). The general pattern is to register `npx -y @xano/developer-mcp` as a stdio server — see any of the pages above for reference.
### Global npm Install
If you prefer a global install instead of `npx`:
```bash theme={null}
npm install -g @xano/developer-mcp
```
Then reference the command directly in your MCP client configuration:
```json theme={null}
{
"xano": {
"command": "xano-developer-mcp"
}
}
```
***
## Xano Skills
The Developer MCP repo also ships two agent skills — portable, agent-neutral prompts that give AI assistants deeper Xano expertise on top of what the MCP provides.
| Skill | Description |
| ------------------------ | --------------------------------------------------------------------------------------------- |
| `xano-init` | Guided setup that profiles a Xano workspace and builds a sandbox-first development playbook |
| `xanoscript-docs-expert` | Deep reference for working with XanoScript documentation and the Developer MCP's architecture |
Skills are distributed via the open Agent Skills standard and install with a single `npx` command — no cloning or manual file copying.
### Install a single skill
```bash theme={null}
npx skills add xano-inc/xano-developer-mcp -s xano-init -a claude-code -g
```
### Install across multiple agents
Install the same skill into several agents at once:
```bash theme={null}
npx skills add xano-inc/xano-developer-mcp -s xano-init \
-a claude-code -a codex -a cursor -a opencode -g
```
Other supported agents include `gemini-cli`, `windsurf`, `continue`, `cline`, and `github-copilot` — see the skills CLI for the full list.
### Flags
| Flag | Purpose |
| ------------ | ---------------------------------------------------------------------------------------------------- |
| `-s ` | Install a specific skill. Drop this flag to install every skill in the repo. |
| `-a ` | Target a specific agent. Repeat the flag for multiple agents. |
| `-g` | Install globally (user profile). Drop this flag to scope the install to the current project instead. |
Start a new agent session after installing so the skill manifest is picked up. Then invoke a skill by name (`xano-init`, `xanoscript-docs-expert`) or just describe the task in natural language.
***
## No Authentication Required
The Developer MCP runs entirely locally and serves documentation and validation tools. It does **not** connect to your Xano instance and requires no access tokens or credentials. Connection to your Xano workspace is handled separately by the [Xano CLI](/xano-cli/get-started).
The APIs documented by the `meta_api_docs` and `run_api_docs` tools do require authentication when you call them directly. The MCP server itself just provides the documentation.
***
## What's Next
Explore all 6 tools available in the Developer MCP
Access MCP resources and use the package as an npm library
# Resources & Library Usage
Source: https://docs.xano.com/developer-mcp/resources
Access XanoScript documentation as MCP resources and use the package as an npm library
Beyond its tools, the Xano Developer MCP also exposes XanoScript documentation as MCP resources for direct access, and can be imported as an npm library for custom integrations.
## MCP Resources
The server exposes 26 XanoScript documentation files as MCP resources. These can be read directly by URI without calling a tool, which is useful for MCP clients that support resource access.
| Resource URI | Description |
| -------------------------------- | ------------------------------------ |
| `xanoscript://docs/readme` | Overview and quick reference |
| `xanoscript://docs/syntax` | Expressions, operators, and filters |
| `xanoscript://docs/types` | Data types and validation |
| `xanoscript://docs/tables` | Database schema definitions |
| `xanoscript://docs/functions` | Reusable function stacks |
| `xanoscript://docs/apis` | HTTP endpoint definitions |
| `xanoscript://docs/tasks` | Scheduled and cron jobs |
| `xanoscript://docs/triggers` | Event-driven handlers |
| `xanoscript://docs/database` | Database operations |
| `xanoscript://docs/agents` | AI agent configuration |
| `xanoscript://docs/tools` | AI tools for agents |
| `xanoscript://docs/mcp-servers` | MCP server definitions |
| `xanoscript://docs/testing` | Unit tests and mocks |
| `xanoscript://docs/integrations` | External service integrations |
| `xanoscript://docs/frontend` | Static frontend development |
| `xanoscript://docs/run` | Run job and service configurations |
| `xanoscript://docs/addons` | Reusable subqueries for related data |
| `xanoscript://docs/debugging` | Logging and debugging tools |
| `xanoscript://docs/performance` | Performance optimization |
| `xanoscript://docs/realtime` | Real-time channels and events |
| `xanoscript://docs/schema` | Runtime schema parsing |
| `xanoscript://docs/security` | Security best practices |
| `xanoscript://docs/streaming` | Data streaming operations |
| `xanoscript://docs/middleware` | Request/response interceptors |
| `xanoscript://docs/branch` | Branch-level settings |
| `xanoscript://docs/workspace` | Workspace-level settings |
***
## npm Library Usage
The `@xano/developer-mcp` package can also be imported directly as an npm library, allowing you to integrate its capabilities into your own applications or build custom MCP servers.
### Installation
```bash theme={null}
npm install @xano/developer-mcp
```
### Entry Points
The package provides three entry points:
| Import Path | Purpose |
| ---------------------------- | -------------------------------------------- |
| `@xano/developer-mcp` | Main library entry (recommended) |
| `@xano/developer-mcp/tools` | Tools module directly |
| `@xano/developer-mcp/server` | Server module (for extending the MCP server) |
### Core Functions
```typescript theme={null}
import {
validateXanoscript,
xanoscriptDocs,
metaApiDocs,
runApiDocs,
cliDocs,
mcpVersion
} from '@xano/developer-mcp';
```
| Function | Description |
| -------------------------- | ---------------------------------------------------- |
| `validateXanoscript(args)` | Validate XanoScript code and get detailed error info |
| `xanoscriptDocs(args)` | Get XanoScript language documentation |
| `metaApiDocs(args)` | Get Meta API documentation |
| `runApiDocs(args)` | Get Run API documentation |
| `cliDocs(args)` | Get CLI documentation |
| `mcpVersion()` | Get the package version |
### Building Custom MCP Servers
If you want to build a custom MCP server that includes XanoScript capabilities, you can use the tool definitions and handler:
```typescript theme={null}
import {
toolDefinitions,
handleTool,
toMcpResponse
} from '@xano/developer-mcp';
// toolDefinitions: Array of MCP tool definitions
// handleTool: Dispatches tool calls to the correct handler
// toMcpResponse: Converts a ToolResult to MCP response format
```
### Utility Functions
```typescript theme={null}
import {
getDocsForFilePath,
extractQuickReference,
getXanoscriptDocsVersion
} from '@xano/developer-mcp';
```
| Function | Description |
| ---------------------------- | ------------------------------------------------- |
| `getDocsForFilePath(path)` | Get matching documentation topics for a file path |
| `extractQuickReference(doc)` | Extract the Quick Reference section from a doc |
| `getXanoscriptDocsVersion()` | Get the documentation version from `version.json` |
### TypeScript Types
All types are exported for TypeScript consumers:
```typescript theme={null}
import type {
ValidateXanoscriptArgs,
ValidationResult,
ParserDiagnostic,
XanoscriptDocsArgs,
XanoscriptDocsResult,
MetaApiDocsArgs,
MetaApiDocsResult,
RunApiDocsArgs,
RunApiDocsResult,
CliDocsArgs,
CliDocsResult,
McpVersionResult,
ToolResult,
DocConfig
} from '@xano/developer-mcp';
```
***
## Source Code
The Xano Developer MCP is open source under the MIT license.
View the source code and contribute
View the package on npm
# Tools Reference
Source: https://docs.xano.com/developer-mcp/tools
Complete reference for all tools available in the Xano Developer MCP
The Xano Developer MCP provides 6 tools for AI-assisted XanoScript development. These tools are automatically available to your AI assistant once the MCP server is connected.
## validate\_xanoscript
Validates XanoScript code for syntax errors. Returns a list of errors with line and column positions, or confirms the code is valid. The language server auto-detects the object type (table, function, query, etc.) from the code syntax.
### Parameters
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ------------------------------- |
| `code` | string | Yes | The XanoScript code to validate |
### Response
| Field | Type | Description |
| --------- | ------- | -------------------------------------------------------------------------------------- |
| `valid` | boolean | Whether the code is valid |
| `errors` | array | List of errors, each with `range` (start/end line and column), `message`, and `source` |
| `message` | string | Human-readable result summary |
### Examples
**Valid code:**
```
validate_xanoscript({ code: "var $result { value = 1 + 2 }" })
```
Returns:
```json theme={null}
{
"valid": true,
"errors": [],
"message": "XanoScript is valid. No syntax errors found."
}
```
**Invalid code:**
```
validate_xanoscript({ code: "var $result { value = }" })
```
Returns errors with the exact line and column where the issue was found, making it easy to pinpoint and fix problems.
Use this tool as you write XanoScript to catch syntax errors before pushing code to Xano. AI assistants will often call this automatically after generating code.
***
## xanoscript\_docs
Retrieves XanoScript programming language documentation. Call without parameters for the overview. Use `topic` for specific documentation, or `file_path` for context-aware docs based on the file you're editing.
### Parameters
| Parameter | Type | Required | Description |
| ----------- | ------ | -------- | ---------------------------------------------------------------------------- |
| `topic` | string | No | Specific documentation topic to retrieve |
| `file_path` | string | No | File path being edited (e.g., `apis/users/create.xs`) for context-aware docs |
| `mode` | string | No | `full` (default) or `quick_reference` for a compact syntax cheatsheet |
### Available Topics
| Topic | Description |
| -------- | ------------------------------------------------------------- |
| `readme` | XanoScript overview, workspace structure, and quick reference |
| `syntax` | Expressions, operators, filters, and system variables |
| `types` | Data types, input blocks, and validation |
| `schema` | Runtime schema parsing and validation |
| Topic | Description |
| ----------- | ----------------------------------------------------------- |
| `tables` | Database schema definitions with indexes and relationships |
| `database` | All `db.*` operations: query, get, add, edit, patch, delete |
| `addons` | Reusable subqueries for fetching related data |
| `streaming` | Streaming data from files, requests, and responses |
| Topic | Description |
| ---------- | --------------------------------------------------------------- |
| `apis` | HTTP endpoint definitions with authentication and CRUD patterns |
| `tasks` | Scheduled and cron jobs |
| `triggers` | Event-driven handlers (table, realtime, workspace, agent, MCP) |
| `realtime` | Real-time channels and events for push updates |
| Topic | Description |
| ------------- | --------------------------------------------------- |
| `agents` | AI agent configuration with LLM providers and tools |
| `tools` | AI tools for agents and MCP servers |
| `mcp-servers` | MCP server definitions exposing tools |
| Topic | Description |
| -------------- | ---------------------------------------------------------------------- |
| `workspace` | Workspace-level settings: environment variables, preferences, realtime |
| `branch` | Branch-level settings: middleware, history retention, visual styling |
| `middleware` | Request/response interceptors for functions, queries, tasks, and tools |
| `integrations` | Cloud storage, Redis, security, and external APIs |
| Topic | Description |
| ------------- | ------------------------------------------------------------ |
| `testing` | Unit tests, mocks, and assertions |
| `debugging` | Logging, inspecting, and debugging XanoScript execution |
| `frontend` | Static frontend development and deployment |
| `run` | Run job and service configurations for the Xano Job Runner |
| `performance` | Performance optimization best practices |
| `security` | Security best practices for authentication and authorization |
### Context-Aware Docs
When `file_path` is provided, the tool automatically returns all documentation relevant to the type of file you're editing. For example:
| File Path | Topics Returned |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| `apis/users/create.xs` | syntax, types, apis, database, testing, integrations, performance, realtime, schema, security, streaming |
| `tables/product.xs` | syntax, tables |
| `agents/support-bot.xs` | syntax, types, agents |
| `functions/utils/format.xs` | syntax, types, functions, database, testing, integrations, performance, realtime, schema, security, streaming, addons |
The `syntax` topic is always included as a foundation. The `readme` topic is never auto-included (call it explicitly for the overview).
### Quick Reference Mode
Use `mode: "quick_reference"` for compact output that only returns the Quick Reference section from each doc. This is recommended when you need to conserve context window space.
### Examples
```
// Get the overview
xanoscript_docs()
// Get full function docs
xanoscript_docs({ topic: "functions" })
// Context-aware: all docs relevant to API files
xanoscript_docs({ file_path: "apis/users/create.xs" })
// Compact quick reference for database operations
xanoscript_docs({ topic: "database", mode: "quick_reference" })
```
***
## meta\_api\_docs
Retrieves documentation for Xano's Meta API, which provides programmatic access to manage workspaces, databases, APIs, functions, agents, and more.
### Parameters
| Parameter | Type | Required | Description |
| ----------------- | ------- | -------- | ------------------------------------------------------------- |
| `topic` | string | Yes | Documentation topic to retrieve |
| `detail_level` | string | No | `overview`, `detailed` (default), or `examples` |
| `include_schemas` | boolean | No | Include JSON schemas for requests/responses (default: `true`) |
### Available Topics
| Topic | Description |
| ---------------- | ------------------------------------ |
| `start` | Getting started with the Meta API |
| `authentication` | API authentication and authorization |
| `workspace` | Workspace management endpoints |
| `apigroup` | API group operations |
| `api` | API endpoint management |
| `table` | Database table operations |
| `function` | Function management |
| `task` | Scheduled task operations |
| `agent` | AI agent configuration |
| `tool` | AI tool management |
| `mcp_server` | MCP server endpoints |
| `middleware` | Middleware configuration |
| `branch` | Branch management |
| `realtime` | Real-time channel operations |
| `file` | File management |
| `history` | Version history |
| `workflows` | Step-by-step workflow guides |
### Detail Levels
* **`overview`** — Returns just the method, path, and description for each endpoint
* **`detailed`** — Includes parameters, request body details, and response schemas
* **`examples`** — Adds full request/response examples with code blocks
### Examples
```
// Get started
meta_api_docs({ topic: "start" })
// Full table management docs
meta_api_docs({ topic: "table", detail_level: "detailed" })
// API examples without schemas
meta_api_docs({ topic: "api", detail_level: "examples", include_schemas: false })
// Workflow guides
meta_api_docs({ topic: "workflows" })
```
***
## run\_api\_docs
Retrieves documentation for Xano's Run API, which provides runtime execution, session management, and XanoScript execution capabilities.
The Run API uses a fixed base URL: `https://app.dev.xano.com/api:run/` — this is **not** your Xano instance URL.
### Parameters
| Parameter | Type | Required | Description |
| ----------------- | ------- | -------- | ------------------------------------------------------------- |
| `topic` | string | Yes | Documentation topic to retrieve |
| `detail_level` | string | No | `overview`, `detailed` (default), or `examples` |
| `include_schemas` | boolean | No | Include JSON schemas for requests/responses (default: `true`) |
### Available Topics
| Topic | Description |
| ----------- | ----------------------------------------- |
| `start` | Getting started with the Run API |
| `run` | Execute XanoScript code and API endpoints |
| `session` | Session management for stateful execution |
| `history` | Execution history and debugging |
| `data` | Data operations and variable management |
| `workflows` | Step-by-step workflow guides |
### Examples
```
// Get started
run_api_docs({ topic: "start" })
// Full execution docs
run_api_docs({ topic: "run", detail_level: "detailed" })
// Session examples
run_api_docs({ topic: "session", detail_level: "examples" })
```
***
## cli\_docs
Retrieves documentation for the Xano CLI (`@xano/cli`), covering local development workflows, code sync, and XanoScript execution from the command line.
### Parameters
| Parameter | Type | Required | Description |
| -------------- | ------ | -------- | ----------------------------------------------- |
| `topic` | string | Yes | Documentation topic to retrieve |
| `detail_level` | string | No | `overview`, `detailed` (default), or `examples` |
### Available Topics
| Topic | Description |
| ------------- | ------------------------------------------------------------ |
| `start` | Getting started — installation and setup |
| `profile` | Profile management — credentials and multi-environment setup |
| `workspace` | Workspace operations — pull/push code sync |
| `branch` | Branch management |
| `function` | Function management — list, get, create, edit |
| `run` | Run API commands — execute code, manage projects/sessions |
| `static_host` | Static hosting — deploy frontend builds |
| `integration` | CLI + Meta API integration guide — when to use each |
### Examples
```
// Get started
cli_docs({ topic: "start" })
// When to use CLI vs Meta API
cli_docs({ topic: "integration" })
// Full workspace commands
cli_docs({ topic: "workspace", detail_level: "detailed" })
```
***
## mcp\_version
Returns the current version of the Xano Developer MCP server.
### Parameters
None.
### Response
Returns the version string (e.g., `"1.0.31"`).
### Example
```
mcp_version()
// Returns: "1.0.31"
```
# Enterprise Features
Source: https://docs.xano.com/enterprise/enterprise-features
Sidecar Docker containers right alongside your Xano instance.
Track all changes across your workspaces.
Enforce security policies for your team members.
Custom deployment options such as on-prem or bring your own cloud.
Control team member permissions throughout your workspaces.
Merge changes between Xano workspaces.
# Compliance Center
Source: https://docs.xano.com/enterprise/enterprise-features/compliance-center
The Compliance Center is included with **Scale** and **Enterprise** plans. Certain plans may not contain all of the available features of the Compliance Center.
## What is the Compliance Center?
The\*\* Compliance Center\*\* provides a comprehensive history of changes made to your workspace objects. This feature allows you to track modifications, understand who made them, when they occurred, and on which Branch.
This detailed tracking offers valuable insights for collaboration, auditing, and understanding the evolution of your project. The Compliance Center records changes to the following workspace elements:
* Database tables and schema
* API groups
* API endpoints
* Addons
* Custom functions
* Background tasks
**Important Note:** Changes to individual records within your database are not tracked by the Compliance Center.
By providing a clear and accessible log of workspace modifications, the Compliance Center enhances team transparency and simplifies the process of understanding project history. This can be particularly useful for:
* **Collaboration:** Easily identify when and by whom specific changes were implemented.
* **Auditing:** Maintain a record of modifications for internal reviews or compliance requirements.
* **Troubleshooting:** Understand recent changes that may have impacted functionality.
* **Onboarding:** Quickly bring new team members up to speed on the project's development.
The Compliance Center is a valuable tool for maintaining a well-documented and understandable development process within your Xano workspaces.
## Using the Compliance Center
To access the Compliance Center navigate to the Settings tab of the workspace, open the menu icon in the top right, and select Compliance.
Inside the Compliance Center, you can access various reporting areas for different types of activity in your workspace.
Each change to a workspace object is recorded in the Compliance Center:
* **ID** - the unique ID of a specific change.
* **Object** - the Workspace Object that was changed.
* **Branch** - which Branch the change occurred on.
* **Author** - the team member that made that change.
* **Date** - the time the change occurred.
### Activity Logs
Activity Logs provide an aggregated dashboard of all admin related activity across the workspace.
### Middleware Reporting
Middlware Reporting allows you to audit your APIs, functions, and tasks to ensure that they are all using the expected [middleware](/the-function-stack/building-with-visual-development/middleware). From this view, you can also review when APIs have customized middleware, meaning they have been given different settings than what is applied at the parent object level.
### Version History
Version History is an aggregated dashboard of all schema changes across tables, APIs, functions, addons, and tasks.
You can click on any one of these items and immediately navigate to the item that was changed to review further as necessary.
### Trigger Reporting
Similar to Middleware Reporting, Trigger Reporting allows you to audit and verify triggers. You can review both database triggers and workspace triggers.
### Instance Activity
The Compliance Center add-on also includes Instance Activity, available from your instance selection screen. Instance Activity offers administrators history on access to the instance. This includes login events and instance access activity, as well as team member management and permission updates. This includes time and date, user name, their location, IP address, and user agent.To access, click the⚙️ icon that appears to the right side of the instance selector, and on the panel that appears, choose Instance Activity.Instance Activity will report on **login**, **instance connect**, **instance update**, **RBAC update**, **Team update**, **Agency update**, **Image Upload**, **Custom Domain Change**, and **License Requests**.
# Deployment
Source: https://docs.xano.com/enterprise/enterprise-features/deployment
## Bring Your Own Cloud (BYOC)
If your organization already operates with a tested and approved Cloud Provider, Xano can be deployed on other providers such as AWS, Azure, or another Google Cloud instance. Each Xano Instance will be hosted within your own cloud account. This provides complete control and access to all of your data and infrastructure. BYOC includes Data Sovereignty, Regional Support, Scaling Configurations, direct access to all resources through RBAC, and the ability to host unlimited Xano instances\* within the GCP account. (*\*Separate licenses are required for each Xano instance*).
## On-Premise
On-premise cloud computing means that an organization uses its own physical infrastructure to deploy cloud resources, ensuring high levels of security. Each Xano Instance will be hosted within your on-premise environment. This option is reserved for organizations that require the utmost security standards.
## Highly Available Edition (Multi-zone Configuration)
Highly Available Edition is recommended for critical production applications or any application needing to minimize downtime and increase reliability. Xano configures multiple zones to ensure continuous operations without failing for a designated period of time. Multi-Zone Configuration helps provide redundancy with data backups across zones, failover capabilities, and automatic recovery. These play an essential role in ensuring organizations meet their availability goals and SLAs. In the event of an outage in one zone, another zone is automatically able to take over helping prevent data loss and maximizing application resiliency.
# Instance Activity
Source: https://docs.xano.com/enterprise/enterprise-features/instance-activity
With Instance Activity, you can easily review critical actions inside of your Xano instance.
The following types of information are available from this panel:
* Login
* When a teammate logs in to their Xano account
* Instance Connect
* When a teammate connects to an instance
* Instance Update
* When a change is made to your instance settings
* RBAC Update
* When a change is made to your [Role-based Access Control](/enterprise/enterprise-features/rbac-role-based-access-control) settings
* Team Update
* When team members are added, removed, or modified
* Agency Update
* If you have an Agency add-on and your agency information is updated
* Image Upload
* If the images on your Agency profile are changed
* Custom Domain Change
* If a change is applied to your custom domain settings
* License Request
* Requests for licenses of the Xano Standalone edition.
You can use the filters in this panel to look at specific time ranges or the events listed above.
# Microservices
Source: https://docs.xano.com/enterprise/enterprise-features/microservices
## What's possible with Microservices?
* Deploy a custom service right alongside your Xano instance to extend the functionality of what you can do without the data leaving your environment
* LLMs and AI models ***(GPU-based deployment is available!)***
* PDF generation (great for secure data requirements like HIPAA)
* Media conversion and processing
* Bring a legacy system into the modern age by deploying it inside of a Docker container alongside your Xano instance
* Let separate teams develop specific services to be used in your Xano environment while other developers and product owners work directly inside of Xano
### Microservice Examples and Tutorials
Deploy secure file conversation as a part of your Xano environment
The Microservice feature is available as an add-on. Please contact your Xano representative or support for details.
## Deploying a Microservice
From your instance selection screen, click the⚙️ icon and choose Microservices from the panel that opens.
#### Deployments
This is where you'll actually deploy your Docker containers
#### Persistent Volumes
If you need persistent storage for one of your microservices, you'll do that here before deployment.
#### Configs
Most microservices will come with a standard configuration. In this section, you can add a customized configuration that better suits your specific needs, if applicable.
You would need to provide a config if you'd like to deploy a Docker image from a private repo.
Click **+Add** under the **Persistent Volumes** section.
**Name:** Provide a descriptive name for your persistent volume. This will help you identify it later.
**Size (Gi):** Please be aware that Xano uses **Gibibytes (Gi)** to denote the size of persistent volumes. A Gibibyte is slightly larger than a Gigabyte (1 GiB = 1024 MiB, while 1 GB = 1000 MB). When planning your storage needs, ensure you are considering the capacity in Gibibytes.
**Type:** Select the type of storage you want to use.
* **SSD (Solid State Drive):** SSD storage offers significantly faster read and write speeds compared to standard storage.
* **Use Cases:**
* **Databases:** Ensuring quick query responses and transaction processing.
* **Caching Layers:** Providing rapid access to frequently used data.
* **High-IOPS Applications:** Applications that perform a large number of input/output operations.
* **Standard:** Standard storage provides a cost-effective solution for data where fast access speeds are not critical for the application's core functionality.
* **Use Cases:**
* **Media Storage:** Storing images, videos, and other large files where retrieval speed is less critical.
* **Logs:** Archiving application logs.
* **Backups:** Storing backup data.
* **Less Frequently Accessed Data:** Data that doesn't require immediate or frequent reads/writes.
**Choosing the Right Storage Type:**
Carefully consider the access patterns and performance requirements of your microservice's data when selecting the storage type. Choosing SSD for performance-sensitive workloads like databases will significantly impact responsiveness. Conversely, using Standard storage for less critical data can help optimize costs.
By configuring persistent volumes, you ensure that your microservice's valuable data persists even if the underlying container or instance is restarted or redeployed.
Click **+Add** under Configs
**Available Config Types and Use Cases:**
The **Type** dropdown offers a variety of options, each suited for different kinds of configuration data:
* **Docker Config:**
* **Description:** This config type is specifically designed to securely store credentials for private Docker container registries. When your microservice's Docker image is hosted in a private registry, Xano needs the necessary username and password (or access token) to pull the image during deployment.
* **Use Cases:**
* **Private Registry Access:** Your organization hosts its Docker images in a private registry on platforms like Docker Hub Private Repositories, Amazon Elastic Container Registry (ECR), Google Container Registry (GCR), or other private registry solutions.
* **Secure Credential Management:** Avoid embedding registry credentials directly in your deployment scripts or environment variables, which can be less secure. Docker Config provides a centralized and secure way to manage these sensitive details within Xano.
* **Example:** You have a private Docker Hub repository `myorg/my-app`. To deploy this microservice in Xano, you would create a Docker Config named `dockerhub-credentials` and provide your Docker Hub username and personal access token. Xano will then use these credentials to pull the `myorg/my-app` image during deployment.
* **Text File:**
* **Description:** A simple way to store plain text configurations. This is useful for basic settings or configuration formats that don't adhere to specific structured formats.
* **Use Cases:**
* **Simple Configuration Flags:** Storing basic on/off switches or textual parameters for your application.
* **License Keys:** Holding software license keys as plain text.
* **Custom Script Parameters:** Providing arguments to shell scripts executed within your microservice.
* **Example:** You might have a microservice that reads a `config.txt` file containing a debug flag: `DEBUG=true`. You can store this in a Text File config named `debug-settings`.
* **JSON File:**
* **Description:** Stores configuration data in the widely used JSON (JavaScript Object Notation) format. This is ideal for structured data that can be easily parsed by most programming languages.
* **Use Cases:**
* **API Endpoint Configurations:** Defining base URLs and specific endpoint paths for external APIs your microservice interacts with.
* **Feature Flags:** Managing the enablement or disablement of specific features within your application.
* **Database Connection Strings (non-sensitive parts):** Storing parts of database connection strings that are not sensitive credentials.
* **Example:** You might have a microservice that needs to connect to a third-party analytics service. You could store the API key and base URL in a JSON config named `analytics-config`:
```json theme={null}
{
"api_key": "your_api_key_here",
"base_url": "[https://api.analytics.com/v1](https://api.analytics.com/v1)"
}
```
* **YAML File:**
* **Description:** Stores configuration data in YAML, a human-readable data serialization language. Often preferred for its cleaner syntax compared to JSON for more complex configurations.
* **Use Cases:**
* **Orchestration Configuration:** Defining how different components of your microservice interact.
* **Complex Application Settings:** Managing numerous configuration options with hierarchical structures.
* **Data Pipeline Definitions:** Specifying the steps and parameters for data processing workflows.
* **Example:** You might configure logging levels and output formats for your microservice using a YAML config named `logging`:
```python theme={null}
level: INFO
format: '%(asctime)s - %(levelname)s - %(message)s'
outputs:
- type: console
- type: file
path: /var/log/app.log
```
* **XML File:**
* **Description:** Stores configuration data in XML. While less common for modern configurations, some legacy systems or specific libraries might still rely on XML.
* **Use Cases:**
* **Integration with Legacy Systems:** Configuring interactions with older systems that use XML for configuration.
* **Specific Library Requirements:** Utilizing libraries within your microservice that expect configuration in XML format.
* **Example:** Configuring a Java-based application that reads its settings from an `app-config.xml` file.
* **Shell File:**
* **Description:** Allows you to store and execute shell scripts. This provides a way to automate setup tasks or provide dynamic configurations based on script output.
* **Use Cases:**
* **Environment Variable Setup:** Generating and exporting environment variables needed by your microservice.
* **Initialization Scripts:** Running setup commands or data migrations during microservice startup.
* **Dynamic Configuration Generation:** Creating configuration files based on external factors or other Configs.
* **Example:** You could have a `setup.sh` script in a Shell File config that checks for the existence of a directory and creates it if it doesn't exist. The output of this script could then be used by your microservice.
* **HTML File:**
* **Description:** Stores HTML content. While not typically used for core application configuration, it could be useful for microservices that serve web content or require embedding HTML snippets.
* **Use Cases:**
* **Custom Error Pages:** Providing custom HTML for error responses.
* **Email Templates:** Storing the HTML structure for emails sent by your microservice.
* **Small Web Content Snippets:** Including static HTML content within your application's responses.
* **Example:** You might have a microservice that sends out welcome emails. The HTML structure of this email could be stored in an HTML File config named `welcome-email-template`.
* **CSS File:**
* **Description:** Stores CSS (Cascading Style Sheets) for styling web content served by your microservice.
* **Use Cases:**
* **Styling Embedded Web Interfaces:** If your microservice exposes a basic web interface, you can manage its styles using CSS Configs.
* **Generating Styled Content:** If your microservice generates HTML, you can store the associated styles separately.
* **Example:** A simple monitoring dashboard exposed by your microservice could have its styles defined in a CSS File config named `dashboard-styles.css`.
* **SCSS File:**
* **Description:** Stores SCSS, a CSS preprocessor that adds features like variables, nesting, and mixins, making CSS more maintainable and powerful.
* **Use Cases:**
* **Advanced Web Interface Styling:** For more complex web interfaces or components within your microservice.
* **Themed Applications:** Managing different visual themes for your microservice's web elements.
* **Example:** You could define color palettes and reusable style rules in an SCSS File config named `theme.scss`.
**Helpers for Adding Configs:**
Xano provides helper buttons to simplify the process of adding certain types of configurations:
* **FROM USER/PASS:** This helper is a shortcut for creating a **Docker Config** by directly prompting you for a username and password.
* **FROM GOOGLE SERVICE ACCOUNT:** This helper assists in configuring access to Google Cloud services containing the necessary service account credentials.
* **FROM AWS:** This helps in configuring access to Amazon Web Services, making it easier to reterieve AWS access keys and secret keys.
By understanding the different Config types and their potential use cases, you can effectively manage your microservice's settings, credentials, and other necessary data within Xano, leading to more robust, secure, and maintainable deployments. Remember to choose the Config type that best suits the format and purpose of your configuration data.
The **Deployment** section is where you define how your microservice, packaged as a Docker image, will be run and managed within Xano. Think of a deployment as the active instance of your microservice.
**Key Concepts:**
* **Docker Image:** The foundational building block of your microservice. It's a standalone package that includes everything needed to run your application: code, runtime, system tools, system libraries, and settings. Docker images can be hosted in public or private repositories.
* **Replicas:** These are the individual running instances of your Docker image. Increasing the number of replicas enhances the availability and scalability of your microservice by distributing incoming requests across multiple instances.
* **Load Balancing:** When you have multiple replicas, Xano automatically distributes incoming API requests across these instances. This ensures that no single instance is overwhelmed and improves the overall performance and resilience of your microservice. Your application should be designed to handle multiple concurrent requests and statelessness to function correctly with replicas.
**Deployment Configuration:**
* **Name:** A unique identifier for this specific microservice deployment within your Xano Function Stack. This name will be used to reference your microservice when building your APIs.
* **Replicas:** Specify the desired number of running instances (replicas) of your Docker image.
* **Recommendation:** It's often best to start with **1 Replica** while you are initially setting up and testing your microservice. Once it's stable, you can increase the number of replicas for better performance and fault tolerance, if your deployment supports them.
* **Docker Config:** Select the configuration to use for accessing your Docker image repository.
* **Public Repo:** Choose this if your Docker image is hosted in a public repository (no authentication required).
* **\:** If your Docker image is in a private repository, the Docker Configs you've set up in the **Configs** section will appear here. Select the appropriate config containing the necessary credentials to pull the image.
* **Strategy:** Defines how updates to your microservice deployment are handled with minimal downtime.
* **RollingUpdate:** This strategy gradually updates your replicas. It brings up a new replica with the updated Docker image before taking down an old one. This ensures minimal interruption to your service.
* **Recreate:** This strategy first takes down all existing replicas and then creates new ones with the updated Docker image. This will result in a period of downtime during the update.
**Containers:**
A deployment can consist of one or more containers. This is useful for running tightly coupled applications that require multiple processes.
* **Name:** A name to identify this specific container within the deployment. This can be the same as the deployment name for single-container deployments or a more specific name for multi-container setups.
* **Type:** Specifies the type of container to run:
* **Standard:** The primary type for running your main application processes. These containers will run continuously as part of your microservice deployment.
* **Initialize Only:** This type of container is designed to run a specific task or set of tasks to completion *before* the Standard containers in the deployment are started. Once the Initialize Only container finishes its execution successfully, it will terminate, and the Standard containers will then be launched.
* **Docker Image:** The URL or identifier of the Docker image to run for this container. This can be a public or private image (authentication for private images is handled at the Deployment level via the "Docker Config").
* **Multi-Container Example:** Imagine a web application that requires a PHP application server and a PostgreSQL database. You could define two containers within the same deployment: one running the PHP Docker image and another running the PostgreSQL Docker image. These containers can then communicate with each other within the deployment's network.
**Ports:**
This section defines how network traffic is routed to your container(s).
* **+ Add Port:** Click this to define a new port mapping.
* **Container Port:** The port that your application *inside* the Docker container is listening on. This is defined by how your Docker image is built.
* **Service Port:** The port that Xano's Function Stack will use to expose your microservice externally. When you make an API request to your microservice in Xano, you will target this service port.
* **Port Mapping:** You can have the Container Port and the Service Port be the same. However, in multi-container deployments, each container that needs to be accessible externally must have a unique Service Port. The Container Port will be specific to the application within each container.
**Environment Variables:**
Environment variables provide a way to configure your containerized application dynamically. These are key-value pairs that can influence the behavior of your application at runtime.
* **+ Add environment variable:** Click this to add a new environment variable.
* **Name:** The name of the environment variable.
* **Value:** The value assigned to the environment variable.
* **Use Cases:** You can use environment variables to pass database connection details (excluding sensitive credentials, which are better managed with Configs), API keys (for non-critical services), or feature flags to your application.
* **Best Practice:** For a large number of configuration parameters, especially sensitive ones, consider using **Config Files** instead of environment variables for better organization and security. The specific environment variables your Docker image expects will be documented by the image provider.
**Volumes:**
Volumes provide persistent storage or configuration files to your containers.
* **+ Add volume:** Click this to add a new volume mount.
* **Name:** A name for this volume mount within the deployment.
* **Type:** Specifies the type of volume to mount:
* **Scratch:** Provides temporary storage that is local to the container instance and is deleted when the container restarts. Useful for ephemeral data like temporary files or caches that don't need to persist.
* **Persistent Volume:** Mounts a persistent storage volume that you configured in the **Persistent Volumes** section. This is essential for data that needs to survive container restarts and deployments, such as database files or uploaded media.
* **Config File:** Mounts a configuration file from the **Configs** section into your container.
* **Config:** If you selected "Config File" as the **Type**, this dropdown will appear, allowing you to choose a specific configuration you've created in the **Configs** section.
* **Mount Path:** The path *inside* the Docker container where the volume or config file will be accessible to your application. This path is determined by how your Docker image is designed to look for these resources.
**Resources:**
This section allows you to define the minimum and maximum CPU and RAM resources that can be allocated to your container(s). You can also specify the number of GPUs (Graphics Processing Units) if your application requires them for tasks like machine learning.
* **Min CPU:** The minimum amount of CPU that will be reserved for each container instance (e.g., 250m represents 0.25 CPU core).
* **Max CPU:** The maximum amount of CPU that each container instance can utilize (e.g., 1000m represents 1 CPU core).
* **Min RAM:** The minimum amount of RAM (memory) that will be reserved for each container instance (e.g., 1024Mi represents 1024 Megabytes).
* **Max RAM:** The maximum amount of RAM that each container instance can utilize (e.g., 2048Mi represents 2048 Megabytes).
* **GPU:** The number of GPUs to allocate to the container (typically used for machine learning workloads).
* **Resource Management:** Properly configuring resource limits helps ensure that your microservice has the resources it needs to run efficiently and prevents a single microservice from consuming all available resources on the underlying infrastructure.
**Docker Entrypoint Command override:**
This is an advanced setting that allows you to override the default entrypoint command defined in your Docker image. The entrypoint is the first command that runs when a container starts.
* **+ Add command:** Click to specify a new entrypoint command.
* **Use Case:** You might use this to run a different executable or script as the main process for your container.
**Docker Entrypoint Arguments override:**
This advanced setting allows you to provide arguments to the overridden entrypoint command.
* **+ Add argument:** Click to add an argument for the overridden entrypoint.
**Affinity and Tolerations:**
These are advanced Kubernetes concepts that control how pods (groups of containers) are scheduled onto nodes (servers).
* **Affinity:** Allows you to define rules about which nodes your pods should or should not be placed on based on labels of other nodes or pods.
* **Use Case:** You might want to ensure that all replicas of a particular microservice are deployed on different nodes for high availability or that certain containers are placed on nodes with specific hardware.
* **Tolerations:** Allow pods to be scheduled onto nodes that have specific taints applied to them. Taints are used to prevent pods from being scheduled onto certain nodes.
* **Use Case:** If you have specialized nodes (e.g., with GPUs), you might apply a taint to them. Only pods with a corresponding toleration can be scheduled onto these nodes.
These advanced settings provide fine-grained control over the placement and scheduling of your microservice containers within the underlying infrastructure. Understanding these concepts can be beneficial for optimizing resource utilization, ensuring high availability, and meeting specific hardware requirements.
### Using a Microservice in the Function Stack
Once deployed, you can interact with the microservice in the Xano Function Stack.
The Microservice function will be similar to an [external API request](/the-function-stack/functions/apis-and-lambdas/external-api-request) function. Although the settings of the function are similar, it's important to call out that the **microservice is all internal traffic, making the interaction secure**.
* **Import Curl** - allows Xano to automatically build the microservice call via a curl command.
* **Host** - Select from a list of your deployments.
* **Path** - define the microservice URL path here.
* **Method** - HTTP method just like an API call (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS)
* **Params** - Any parameters or request body required.
* **Headers** - Define any custom headers.
* **Timeout** - Defines how long the Function Stack will wait in seconds before it considers the Function to be timed out.
* **Follow\_location** - determines if you wish to automatically follow the redirects (if there are any) in the microservice.
For more on Import Curl, Method, Params, Headers, Timeout, and Follow\_location check out the [External API Request](/the-function-stack/functions/apis-and-lambdas/external-api-request) page.
# Ollama
Source: https://docs.xano.com/enterprise/enterprise-features/microservices/ollama
Deploy LLMs as a part of your Xano instance
**Quick Summary**
Through Xano's Microservice feature, you can deploy [Ollama](https://ollama.com/) as a part of your Xano instance, enabling secure communication with an off-the-shelf or customizable LLM tailored specifically to your needs.
## What is Ollama?
Ollama is a platform that enables seamless integration of large language models (LLMs) into various applications. It provides an environment where businesses can deploy pre-built or customized LLMs, facilitating secure and efficient communication tailored to specific business needs.
This makes it easier for companies to leverage advanced AI technology without extensive in-house development, and without the concerns of sending data to a third-party AI provider. In addition, deploying Ollama as a part of your Xano instance can be a significant cost-saving measure in comparison to leveraging a third party service.
## What can I do with Ollama + Xano?
Deploying Ollama as a microservice in Xano helps address a **critical data privacy challenge** when building AI-enabled applications that handle sensitive information.
By processing data within your controlled infrastructure boundary rather than sending it to external AI providers, using Xano with microservices removes one significant barrier to developing secure applications that can still leverage the benefits of AI models.
*While this approach addresses an important technical aspect of data privacy, comprehensive security and compliance will require implementing additional safeguards appropriate to your specific regulatory environment.*
## Getting Started
[Talk to Sales](https://www.xano.com/enterprise/)
You'll want to know which model you're deploying so we understand the resources that need to be allocated. Check out the resource linked below if you need help choosing a model.
[Choosing a Model](/enterprise/enterprise-features/microservices/ollama/choosing-a-model)
A persistent volume is just a place that the microservice can store data that remains between restarts. Ollama will use this volume to store the model(s) that you're working with.
**How much storage do I need?**
When browsing Ollama models, use the Size column for your chosen model to determine how large of a volume you should deploy. Make sure to add a little extra when creating your volume, just for some breathing room.
Name the volume `ollama`, select the size, and choose `SSD` as the storage class. When you're ready, click Add
Click Add under Deployments
Fill out the following information. For this example, we'll be deploying the `phi3:mini` model, which should work with the following example values.
| Parameter | Purpose | Example Value |
| ---------------------- | ---------------------------------------------------------------------- | ---------------------- |
| Deployment Name | Name of the deployment | `ollama` |
| Replicas | Number of container instances | `1` |
| Docker Config | Source of the Docker image | `public repo` |
| Deployment Strategy | Update strategy | `RollingUpdate` |
| Container Name | Name of the container | `ollama` |
| Container Type | Container type | `Standard` |
| Docker Image | Docker image to use | `ollama/ollama` |
| Container Port | Port the container listens on | `11434` |
| Service Port | Port exposed to the service | `11434` |
| Persistent Volume Name | Name of the persistent storage volume you created in the previous step | `ollama` |
| Volume Type | Volume type | `Persistent Volume` |
| Mount Path | Path in container where volume is mounted | `/root/.ollama/models` |
| Min CPU | Minimum CPU allocation | `500m` |
| Max CPU | Maximum CPU allocation | `2000m` |
| Min RAM | Minimum RAM allocation | `4096Mi` |
| Max RAM | Maximum RAM allocation | `8192Mi` |
Click Add and then Update & Deploy
All interactions with Xano microservices are facilitated by the Microservice function, which is a REST API request to your chosen microservice.
Use the cURL below to get started. Add a Microservice function to your function stack, and click Import cURL
```cpp theme={null}
curl -X POST http://localhost:11434/api/pull \
-H "Content-Type: application/json" \
-d '{
"name": "phi3:mini"
}'
```
Please note that the `Content-Type: application/json` header is **required**, or your requests will fail.
Click on the `host` dropdown and choose your deployment, likely called `ollama`
Change the timeout to a value that will allow you to monitor the deployment right inside of Xano. Below are some recommended values. You can also monitor the deployment via the logs of the microservice, available from your instance settings where you deployed the microservice earlier.
| | | |
| -------------------- | ------------- | ---------------- |
| `phi3:mini` (\~5 GB) | 10–60 seconds | **5 min (300s)** |
| | | |
| --------------------- | -------------- | ----------------------- |
| `mistral:7b` (\~8 GB) | 30–120 seconds | **5–10 min (300–600s)** |
| | | |
| ---------------------- | -------------------- | ------------- |
| `llama3:70b` (\~40 GB) | 5–20 minutes or more | **15–30 min** |
Once the model has downloaded, you'll be returned a 200 status response, as shown below. The model will be saved to your persistent storage volume, so you should only have to do this once.
You're ready to receive generations from your Ollama microservice. Here's an example cURL command to get you started.
```cpp theme={null}
curl -X POST http://localhost:11434/api/generate \
-H "Content-Type: application/json" \
-d '{
"model": "phi3:mini",
"prompt": "Explain the difference between supervised and unsupervised learning.",
"stream": false
}'
```
The above command will return an output like the one shown below.
Ollama offers a set of standard commands that can be issued via REST API endpoints. You can review them [here](https://www.postman.com/postman-student-programs/ollama-api/documentation/suc47x8/ollama-rest-api), and use them as necessary inside of your function stacks.
# Choosing A Model
Source: https://docs.xano.com/enterprise/enterprise-features/microservices/ollama/choosing-a-model
When selecting an Ollama model for your specific needs, it's important to consider a few key factors that will influence performance and suitability. Below are the steps to help you make the best choice
Clearly outline what you aim to achieve with leveraging an LLM as a part of your backend. Consider the model's application--whether it's natural language processing, predictive analysis, or any other specific task.
## **Ask yourself:**
Are you building a chatbot, summarizing content, analyzing sentiment, or extracting structured data?
**Examples & Recommendations:**
* **Chatbot or general assistant:** `llama3`, `mistral`, `gemma`
* **Content summarization or rewriting:** `llama2`, `phi`, `mistral`
* **Code generation or technical Q\&A:** `codellama`, `deepseek-coder`
* **Specialized reasoning tasks:** `wizardlm`, `nous-hermes`
Evaluate the types and quantity of data accessible for training and testing. Ensure the model you choose can work effectively with your data type and size. This is especially important if you plan to work with data other than plain text, such as images or video.
## **Ask yourself:**
Will the model handle text, images, code, or a combination?
**Examples:**
* For **text-only workflows**, most Ollama models (like `mistral`, `llama3`, or `phi`) work well.
* If you're working with **multimodal inputs** (images, audio), consider an external pipeline—Ollama currently focuses on LLMs optimized for text.
* **Simple Models**: If your application requires quick results and you have less computational power, opt for simpler models. They're easier to implement and require less processing time.
* Use for fast, low-latency tasks on smaller infrastructure.
* *Examples:* `phi`, `tinyllama`, `gemma`
* **Complex Models**: For tasks demanding high accuracy and working with large-scale data, or different data types such as images, audio, or video, complex models are usually a better option.
* Better for high-accuracy, large-context reasoning or specialized use cases.
* *Examples:* `llama3:70b`, `wizardlm`, `codellama:34b`
Analyze the budget you have against the cost of implementing and running the model. If you need assistance with this, reach out to your Xano representative.
* **Cost-Effective Models**: Great for limited budgets but may sacrifice some accuracy or features.
* **Premium Models**: Require a higher investment but provide better accuracy and features.
## **Ask yourself:**
* Do I need real-time responses, or can I batch responses?
* What’s my budget for GPU or CPU usage?
**Cost-Saving Models:** `phi`, `gemma`, `tinyllama` **Premium / High-Capacity Models:** `llama3:70b`, `codellama:34b`, `wizardlm:uncensored`
Select an Ollama model backed by strong community support or vendor assistance. This will aid in troubleshooting issues or optimizing performance.
**Recommended:**
* `llama3`, `mistral`, `codellama` all have strong GitHub and forum support.
* Stick with models that are well-documented and frequently updated.
| Use Case | Recommended Models |
| ---------------------------- | ----------------------------------------- |
| Lightweight Chatbot | `phi`, `gemma`, `tinyllama` |
| Developer Assistant | `codellama`, `deepseek-coder` |
| Content Generation | `mistral`, `llama3`, `nous-hermes` |
| Reasoning & Q\&A | `wizardlm`, `llama3:70b` |
| Small Infra / Fast Load | `phi`, `gemma` |
| High Accuracy / Large Scale | `llama3:70b`, `wizardlm`, `codellama:34b` |
| Budget-Conscious Deployments | `phi`, `gemma`, `tinyllama` |
| Strong Community Support | `mistral`, `llama3`, `codellama` |
# RBAC (Role-based Access Control)
Source: https://docs.xano.com/enterprise/enterprise-features/rbac-role-based-access-control
RBAC is available with Pro and Custom plans. On a different plan and want access? [Contact sales](https://xano.com/sales) to upgrade.
Role-based Access Control allows you to build custom user roles and assign granular workspace-level permissions for your team members. Use Xano's RBAC feature to ensure team members only have access to and can only take action on the things that should be available to them.
Define custom roles with the right level of access for each kind of team member.
Apply a role when inviting a user, or adjust per-workspace permissions later.
Copy/paste permissions between users and apply roles or changes to many at once.
What each permission unlocks across the instance, workspace, and tenant center.
## Accessing RBAC
From the [instance selection screen](https://app.xano.com/instance), click the icon and choose Permissions (RBAC).
## The Permissions Center
Xano offers five pre-defined user roles as described in the table below.
| Role | Intended use | Access summary | Key limitations |
| ------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Admin** | Full administrative access across the instance, workspace, releases, tenant center, and tenant cluster. | Full access to workspace resources, release management, tenant center, backups, secrets, tenant cluster, RBAC, logs, deploy, impersonation, metadata API, exports, run/debug, and marketplace/connect features. | None in the predefined matrix. |
| **Developer** | Build and manage workspace functionality without full tenant/security administration. | Full access to most workspace resources, including database, content, APIs, functions, tasks, services, middleware, files, logs, settings, release, tenant center, backups, deploy, impersonation, metadata API, marketplace/connect, export, and run/debug. | Cannot manage Tenant Center RBAC, Tenant Center Secrets, Tenant Cluster, Tenant Cluster Secrets, or debug from request history. |
| **Readonly** | Review configuration, data, logs, and release/tenant information without making changes. | Read access to most workspace resources, release, tenant center, and tenant center logs. | Cannot create, edit, export, run/debug, use marketplace/connect, manage RBAC, deploy, impersonate, access secrets, backups, metadata API, or tenant cluster resources. |
| **Billing** | Limited access for billing or account-level visibility. | Read access to the instance workspace only. | No access to workspace resources, releases, tenant center, tenant cluster, logs, exports, run/debug, or feature actions. |
| **Suspended** | Temporarily or permanently block a user's access. | No access. | All permissions are disabled. |
### Creating roles
Before inviting team members to your instance, make sure the proper roles are ready to use.
In the **Roles** tab, click Add new custom role
Give the new role a name, and click Add Custom Role
You'll see your new role appear in the list of roles below the Xano defined options.
A new role comes with all permissions enabled by default.
Click on a permission to adjust it for that role. There are four levels of access for each permission: **Create (C)**, **Read (R)**, **Update (U)**, and **Delete (D)**. Some, depending on context of the permission, will only offer **Enabled** or **Disabled**. There are also **-** and **+** options to quickly add or remove all permissions for that feature.
Active users inside the Instance won't be immediately impacted by changes to permissions. They will have to leave the Instance and re-enter for changes to take effect.
### Assigning roles
You can assign a role to a user when inviting them to your instance.
If they are already a member of your instance, you'll see them listed under each workspace in the **Workspace** tab of the Permissions Center, and you can granularly adjust their permissions for each workspace.
You can also filter the Workspace tab by team member and workspace to focus on one person's access across the instance, or to see who has access to a specific workspace.
To change a user's role after they've already been invited, click the next to your instance on the instance selection screen and choose **Manage Team**.
### Adjusting permissions
Click on a permission to adjust it for that user. There are four levels of access for each permission: **Create (C)**, **Read (R)**, **Update (U)**, and **Delete (D)**. Some, depending on context of the permission, will only offer **Enabled** or **Disabled**. There are also **-** and **+** options to quickly add or remove all permissions for that feature — turning everything on is sometimes referred to as **Full** access.
When adjusting permissions for a user on a specific workspace, you'll also see an **Inherit** option, which means that permission will obey what's defined by the assigned role.
**Inherit example:** If you set Jane's Run & Debug permission on Workspace A to **Inherit**, and Jane's assigned role is **Developer**, then Jane's Run & Debug access on Workspace A will match whatever the Developer role allows for Run & Debug. Change the role later and Jane's inherited permissions follow automatically.
### Bulk operations
You can manage permissions for many users at once from the **Workspace** tab of the Permissions Center.
#### Copy/paste permissions
Use **Copy/Paste Permissions** to quickly give one team member the same permissions as another — useful when several team members need identical access across each workspace.
Click the **Copy/Paste** button, choose the team member to copy permissions from, then choose the team member to paste permissions to.
#### Bulk role assignment
Click the three dots above the roles list to open the bulk menu. Choose **Managing Team Roles**, select the role you want to apply, then select the users to apply it to. The role is applied to every selected user at once.
#### Bulk permission editing
From the same three-dot menu, choose **Bulk Editing Permissions**. Select the users you want to modify, then select the workspaces those changes should apply to. Adjust permissions as needed — any row left as **Unmodified** is skipped, so you only change what you explicitly set.
## Permissions explained
Below, you'll find a rundown of each permission and exactly what it changes for that user. Expand any permission to see its details.
### Workspace & data
The master gate for the entire workspace. Without **Read**, a user cannot see or enter any workspace at all.
**Related docs:** [Workspace Settings](/xano-features/workspace-settings)
| Level | Controls |
| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Read | Whether workspaces appear in the workspace list and selector. |
| Create | The "Create Workspace" button on the workspace list page. Also required to deploy a Release back into a workspace as a new branch. |
| Update | Renaming a workspace, changing its description, toggling and configuring Swagger docs, and changing push preferences. Also required to import a workspace via the metadata API. |
| Delete | Deleting a workspace — permanently destroys the workspace and all of its schemas, APIs, functions, tasks, middleware, files, and data. Blocked if any tenants are still active. |
Importing a workspace export via the Metadata API requires **Update**, not **Create**. A user who can create new workspaces but lacks **Update** cannot restore from a file.
Schema-level operations on database tables.
| Level | Controls |
| ------ | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Read | Visibility of the Database section |
| Create | Adding new tables and columns (manually or via the AI assistant). |
| Update | Modifying existing tables — renaming columns, changing types, editing relationships, adjusting indexes. Required to save any schema change. |
| Delete | Deleting tables and removing columns. |
Does not affect data records inside tables.
Read/write access to actual data inside database tables.
| Level | Controls |
| ------ | ---------------------------------------------------------------- |
| Read | Viewing table records; required to export data. |
| Create | Adding new rows; importing records. |
| Update | Editing cell values, pasting into cells, bulk-update operations. |
| Delete | Deleting individual rows, bulk row deletion, table truncation. |
A secondary check that limits data operations specifically when the user's active datasource is the live/production branch. Always checked alongside Database Content — both must allow the action.
**Related docs:** [Data Sources](/the-database/database-basics/data-sources)
It uses the same C/R/U/D shape as Database Content, but applies only when the live datasource is selected. This lets you grant a user full edit access on staging while preventing any writes against production.
File storage — the workspace's vault of uploaded files (images, attachments, documents).
**Related docs:** [File Storage in Xano](/file-storage/file-storage-in-xano)
Standard C/R/U/D on files and access to the file manager.
### Build & logic
| Level | Controls |
| ------ | --------------------------------------------------------------------------------------------------------- |
| Read | Visibility of the APIs section, API groups, and individual endpoints. |
| Create | Adding new API endpoints (from the editor, the AI assistant, the clone panel, or the quick-create modal). |
| Update | Editing endpoint logic, settings, inputs, and outputs. |
| Delete | Removing endpoints and API groups. |
Reusable custom functions across the workspace.
**Related docs:** [Custom Functions](/building/logic/custom-functions)
Standard C/R/U/D on functions. Adding a function from inside the process stack requires **Create**.
Scheduled background tasks.
**Related docs:** [Background Tasks](/building/logic/background-tasks)
Standard C/R/U/D on tasks and access to the Tasks section.
Request/response middleware — pre- and post-processing logic that wraps API endpoints.
**Related docs:** [Middleware](/building/logic/middleware)
Standard C/R/U/D on middleware definitions and access to the Middleware section. **Read** is also required for middleware to appear in the workspace settings modal's Middleware Defaults section.
Addons — enrich database operations with data from related tables.
**Related docs:** [Addons](/building/logic/addons)
Standard C/R/U/D on addon definitions and access to the Addons section.
Shared Services
| Level | Controls |
| ------ | ---------------------------------------------------- |
| Read | Visibility of the Services section. |
| Create | Creating new shared services. |
| Update | Editing services; saving changes to shared services. |
| Delete | Removing shared services. |
AI Tools for AI Agents and MCP servers built in Xano
**Related docs:** [MCP Builder](/ai-tools/mcp-builder) · [AI Agents](/ai-tools/agents)
| Level | Controls |
| ------ | ------------------------------------- |
| Read | Visibility of the AI Tools sections. |
| Create | Adding new tools |
| Update | Editing tool configuration; renaming. |
| Delete | Removing tools |
Realtime channels and settings
**Related docs:** [Realtime in Xano](/realtime/realtime-in-xano)
| Level | Controls |
| ------ | -------------------------------- |
| Read | Visibility of realtime channels. |
| Create | Adding new realtime channels. |
| Update | Editing channel configuration. |
| Delete | Removing channels. |
End-to-end workflow testing — automated test scenarios for APIs, functions, and other logic.
**Related docs:** [Test Suites](/testing-debugging/test-suites)
Standard C/R/U/D on workflow tests. Test execution itself reuses the Functions permission.
### Run & debug
The "Run & Debug" panel that executes any workflow from inside of Xano.
When **Enabled**, the user sees the "Run & Debug" button on every editable workflow — APIs, custom functions, tasks, middleware, workspace triggers, addon functions, and workflow tests — and can launch it. When **Disabled**, the button and the keyboard shortcut are hidden, all inputs in the panel are locked, and execution is impossible from any surface.
Read-only access to view code is unaffected. This permission only governs execution.
Does not distinguish between branches — a user with this permission on a live branch can run against production data unless also restricted by Live Datasource.
The Request History feature — a captured log of API requests that can be replayed and inspected.
**Related docs:** [Request History](/maintenance-monitoring-and-logging/request-history)
| Level | Controls |
| ------ | -------------------------------------------------------------------------------------------------------------------------------- |
| Read | Visibility of request history; loading the dashboard's history widget; required for the toolset page's history playback feature. |
| Update | Changing request history retention settings; enabling history playback in the toolset page. |
| Delete | Clearing request history. |
The "Activate Debugger" button inside the Request History panel — replays a captured request through the Run & Debug panel.
**Related docs:** [Request History](/maintenance-monitoring-and-logging/request-history) · [Testing and Debugging Function Stacks](/testing-debugging/testing-and-debugging-function-stacks)
When **Enabled**, clicking a request history item shows an "Activate Debugger" button. Clicking it pre-populates the Run & Debug panel with that request's captured inputs and (for non-tenant sessions) re-executes against current code; for tenant impersonation sessions, it shows the historical result read-only. A confirmation prompt appears before re-running against a live branch or production datasource.
**Important nuance:** The replay always runs against current code, not the historical snapshot. Historical inputs combined with current logic can yield different results than the original captured request.
This is separate from Run & Debug — a user could theoretically have one without the other (unusual but possible).
### Settings & integrations
Access to the Workspace Settings modal and all of its sub-panels — a multi-section configuration surface covering most workspace-level preferences.
**Related docs:** [Workspace Settings](/xano-features/workspace-settings) · [Environment Variables](/building/logic/working-with-data/environment-variables) · [Git Sync](/xano-features/workspace-settings/git-sync)
| Level | Controls |
| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Read | Opening the Workspace Settings modal at all. The "Settings" sidebar nav item is hidden without it. |
| Create | Adding new Workspace Triggers and Processing Jobs. |
| Update | Saving changes to any of the following sections: General (name, description, Swagger, doc token, AI settings); Branch Defaults (request history retention); Environment Variables; Git Sync (GitHub repo for XanoScript backup); Middleware Defaults (workspace-wide middleware); Realtime configuration; Database Preferences (table format, custom SQL names, PK type); Xano Link (cross-workspace API distribution). Also required to save the Database Connector configuration (in the "Connect" modal, despite the name) and to delete a workspace. Also gates the Environment Variables and Unit Tests pages. |
| Delete | Removing a Git Sync connection. |
**Big surface area.** This permission spans 10+ distinct sub-features. The most common ones to call out are env vars, Git Sync, and realtime config.
The Database Connector lives under "Connect," not "Settings," but is still gated by Workspace Settings **Update** — an easy point of confusion.
The workspace's audit/compliance log — a record of administrative actions taken in the workspace (separate from request traffic logs).
**Related docs:** [Audit Logs](/xano-features/workspace-settings/audit-logs)
Standard C/R/U/D on the log. **Read** is required to view the log list.
**Not request logs.** This is the audit trail (who did what), not the captured-request log. Request traffic lives under Request History.
Workspace export operations — both schema/logic exports and data exports.
**Related docs:** [Export & Sharing](/the-database/database-basics/export-and-sharing)
When **Enabled**, the user can run two distinct exports from inside the Workspace Settings modal:
1. **XanoScript MultiDoc Export** — exports the workspace as a XanoScript document containing schemas, logic (functions/queries/tasks/middleware/etc.), env vars, records, drafts, workflow tests, actions, and triggers (each toggleable). Useful for version control and migration.
2. **Data Export** — exports database records (and optionally hosted files) as a downloadable archive. Runs in the background; you will receive an email with a 12-hour download link when complete.
When **Disabled**, both export buttons are hidden/disabled.
**Sensitive content warning:** The MultiDoc export can include environment variable values (these often contain API keys and other secrets). Document this if exposing the feature to users with low trust.
The Marketplace, where users can install Xano-provided workspace templates.
**Related docs:** [Marketplace](/marketplace)
When **Enabled**, the Marketplace nav item appears in the workspace sidebar and Marketplace pages are accessible. However, you will still need to enable the Marketplace inside of the workspace along with this permission. When **Disabled**, the entire Marketplace feature is hidden.
Third-party platform integrations with specific Connect statements (e.g. Webflow). This does **not** impact access to the External Database Query functions.
**Related docs:** [Connect](/connect)
When **Enabled**, the user can save and manage Connect integration configurations. When **Disabled**, the Connect modal's actions are blocked.
### Releases & Tenant Center
Releases — named, versioned snapshots of a workspace branch that can be deployed to tenant environments. This permission is enforced for Metadata API access (used by CI/CD pipelines and the Xano MCP server). The Tenant Center's release-deploy flow uses Tenant Center Deploy instead.
**Related docs:** [Branching & Merging](/team-collaboration/branching-and-merging) · [Xano CLI Releases](/xano-cli/releases)
| Level | Controls |
| ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Read | List releases; get release details; export a release as a XanoScript MultiDoc; get a signed download URL for the release archive. |
| Create | Create a release from a named branch; create a release from a MultiDoc upload; import a `.tar.gz` release archive; deploy a release back into a workspace as a new branch. |
| Update | Rename or update the description of an existing release. |
| Delete | Permanently delete a release. |
The master gate for the Tenant Center — the workspace-level interface for managing isolated tenant environments (each tenant has its own database and receives logic from releases).
**Related docs:** [Tenant Center](/enterprise/enterprise-features/tenant-center)
| Level | Controls |
| ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Read | Whether the Tenant Center nav item appears at all, and which individual tenants are visible (Read can be granted per-tenant via overrides). Without it, the user sees an upsell page instead. |
| Create | The "Add Tenant" button — provisioning a new tenant environment. |
| Update | Editing tenant properties: display name, description, custom domain, RBAC toggle, task and ingress toggles. |
| Delete | The per-row "Delete" action — permanently destroys a tenant and its infrastructure. |
The Tenant Center is also subject to a plan/feature gate checked separately from RBAC: the instance must have at least one tenant slot allocated. Both must pass for the UI to show.
Manages the tenant's own role-based access control — distinct from the top-level workspace RBAC. Governs which roles, permissions, and team members exist inside RBAC-enabled tenants.
**Related docs:** [Tenant Center](/enterprise/enterprise-features/tenant-center)
When **Enabled**, you'll see the "RBAC" / "Manage Members" button in the Tenant Center header and can open the tenant-RBAC management panel to view and edit roles, permissions, and member assignments for tenants that have RBAC turned on. When **Disabled**, the button is hidden and the panel is read-only or inaccessible.
The Tenant Center audit log — a structured record of administrative actions performed against tenants (creation, deletion, deployment, impersonation, license views, env var changes, backups, etc.).
**Related docs:** [Tenant Center](/enterprise/enterprise-features/tenant-center) · [Audit Logs](/xano-features/workspace-settings/audit-logs)
When **Enabled**, the user sees the "Audit Logs" button in the Tenant Center header (showing logs across all tenants) and a "Logs" action in each tenant's row menu (showing logs for that one tenant).
These are audit logs, not request/traffic logs. They record administrative events, not API request data. API traffic is in Request History.
Backup operations for tenant environments — full snapshots of tenant data that can be restored later.
**Related docs:** [Tenant Center](/enterprise/enterprise-features/tenant-center) · [Backup & Restore](/xano-features/instance-settings/backup-and-restore)
| Level | Controls |
| ------ | -------------------------------------------------------------------------------------------- |
| Read | Listing backups; downloading a backup archive. |
| Create | Creating a new backup; importing a backup file. |
| Update | Restoring a tenant from a backup (replaces all current tenant data); importing backup files. |
| Delete | Deleting backup archives. |
The Restore operation maps to **Update**, not **Create**.
A multi-purpose permission covering four distinct deployment-related actions in the Tenant Center.
**Related docs:** [Enterprise Deployment](/enterprise/enterprise-features/deployment) · [Resource Management](/enterprise/enterprise-features/resource-management)
When **Enabled**, the user can access:
1. **Deploy Release** — push a versioned logic release to one or more tenants in bulk. Available for all tenants. Diff viewing is supported before confirming.
2. **Deploy Platform** — tier2/tier3 only. Migrate a tenant from one infrastructure platform to another (used during Xano-managed platform upgrades).
3. **Manage Resources** — tier2/tier3 only. Configure compute resources for a tenant: CPU/RAM per deployment, replica counts, node affinity, toleration effects, storage settings.
4. **Infrastructure** — tier2/tier3 only. View the live infrastructure state of a tenant: pods, deployments, services, storage volumes, ingresses, jobs. Read-only monitoring view.
Also gates the top-level "Releases" panel in the Tenant Center header.
**Easy to confuse:** Deploy Release pushes application logic; Deploy Platform moves the underlying Xano version. They are different operations entirely.
The Infrastructure panel is read-only but still requires this permission to open.
Impersonation — opening a live workspace session inside a tenant environment as the calling user.
**Related docs:** [Tenant Center](/enterprise/enterprise-features/tenant-center)
When **Enabled**, the user sees the "Impersonate" action in each tenant's row menu. Clicking it generates a one-time token, exchanges it for tenant-scoped credentials, and opens the target tenant's workspace in the browser. The session is bound to the impersonating user's identity — all actions taken inside the tenant are attributed to them, and the impersonation event itself is recorded in the tenant audit log.
Impersonation respects the tenant's RBAC configuration once inside — the impersonating user may have different access in the tenant than they do in the parent workspace.
Not available when a tenant has a Proxy URL configured.
The gateway permission for the Xano Metadata API in tenant context. The Metadata API exposes machine-readable endpoints for all workspace operations (creating tables, deploying releases, managing API groups, etc.) and is consumed by external CI/CD pipelines, the Xano MCP server, and the Metadata API Explorer.
**Related docs:** [Metadata API](/xano-features/metadata-api)
When **Enabled**, the user's access token is allowed to authenticate and call any Metadata API endpoint that resolves to a tenant context. When **Disabled**, all Meta API calls to tenant-scoped resources are rejected regardless of the token's other permissions.
This is an unlock prerequisite, not a full bypass. After granting it, the token still obeys all other workspace-level permissions for each individual endpoint.
Sensitive tenant data — covers two distinct surfaces: the tenant License and tenant Environment Variables.
**Related docs:** [Tenant Center](/enterprise/enterprise-features/tenant-center) · [Environment Variables](/building/logic/working-with-data/environment-variables)
| Level | Controls |
| ------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| Read | Opening the License panel (showing the raw license/credential string for tier3 tenants); viewing environment variable names and values. |
| Create | (Implicit in **Update** for env vars — the same operation adds or replaces values.) |
| Update | Saving changes to the License; adding or modifying env vars; replacing the entire env var set. |
| Delete | Removing individual environment variables. |
The two surfaces are:
* **License** — for tier3 (self-hosted / Regional Isolation) tenants, the license contains cluster credentials or external database connection strings. Exposure allows direct database or cluster access outside the Xano platform, hence treated as a secret.
* **Environment Variables** — key-value pairs injected into the tenant runtime; typically API keys, connection strings, and feature flags.
The default for standalone deployments is full access. Self-hosted Xano users should review this — it exposes infrastructure credentials to all developers by default.
### Tenant clusters
Tenant Clusters — registered remote clusters used to host tier3 (Regional Isolation) tenants. Self-hosted/enterprise feature only; available when the instance has tier3 tenant slots allocated.
**Related docs:** [Resource Management](/enterprise/enterprise-features/resource-management)
| Level | Controls |
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Read | Visibility of the "Tenant Clusters" nav item and the cluster list; viewing individual cluster details. Also disables the "Create Workspace" button when an existing cluster is detected. |
| Create | The "Add new cluster" button — registers a new remote cluster with its credentials, domain, type (standard vs run), warm instance pool sizing, and ingress configuration. |
| Update | Editing cluster name, description, domain, type, warm pool sizes, ingress rules. |
| Delete | Removing a cluster registration. |
Cluster registration stores credentials at create time; subsequent credential management is governed by the separate Tenant Cluster Secrets permission.
The cluster credentials stored for each registered remote cluster — the complete credential set for managing that cluster.
**Related docs:** [Resource Management](/enterprise/enterprise-features/resource-management)
| Level | Controls |
| ------ | --------------------------------------------------------------------------------------------- |
| Read | The "Credentials" button on a cluster's view panel; viewing the raw credential configuration. |
| Update | Saving replacement cluster credentials. |
Both **Read** and **Update** events are written to the audit log.
**Highest-privilege permission.** Exposure of these credentials grants full control over the remote cluster — this should be granted only to operators who need to rotate or inspect credentials.
Distinct from Tenant Center Secrets (which covers tenant database credentials, not cluster-level credentials).
# Resource Management
Source: https://docs.xano.com/enterprise/enterprise-features/resource-management
BYOC (Bring your own Cloud) users can manage their available instance resources from their instance settings
Make sure you are aware of your maximum available resources within the cluster before making any adjustments to these settings.
These settings can consist of maximum CPU/RAM per node (or server), as well as the maximum number of nodes that can exist within the environment.
Maximum restrictions are in place to prevent infrastructure costs from increasing unexpectedly. It is very easy to request excessive amounts of resources, so these safeguards help keep things aligned to the current expectations you have for your backend performance and cost.
The maximum restrictions can be adjusted at the infrastructure level if you have outgrown your current allotment.
If you aren't sure how to proceed, contact our support team for details.
## What is Resource Management?
The Resource Management panel allows Custom and Enterprise BYOC (Bring Your Own Cloud) customers to configure CPU, RAM, and storage allocation for different components of your Xano instance.
## Accessing Resource Management
## Types of Resources
Resource Unit Measurements
Understanding the units used in Xano's resource allocation is essential for proper configuration.
**CPU Measurements**
* **m (millicores):** 1000m = 1 CPU core
* **Examples:** 5m (very light), 100m (moderate), 1000m (1 full core)
**RAM Measurements**
* **Mi (Mebibytes):** 1024Mi = 1 GB
* **Examples:** 512Mi (0.5 GB), 1536Mi (1.5 GB), 2048Mi (2 GB)
**Storage Measurements**
* **Gi (Gibibytes):** 1Gi = 1.07 GB
* **Examples:** 10Gi (≈11 GB), 100Gi (≈107 GB)
### Backend Resources
The **Backend** handles your API endpoints, most of your business logic execution, and core Xano functionality. This is typically your primary compute workload.
**Configuration Options:**
* **Requested CPU:** Minimum CPU allocation
* **Limit CPU:** Maximum CPU the backend can consume
* **Requested RAM:** Minimum memory allocation
* **Limit RAM:** Maximum memory the backend can use
### Backend Autoscaler
The **Autoscaler** automatically adjusts the number of backend pods based on CPU utilization to handle varying traffic loads.
**Configuration Options:**
* **CPU Threshold:** Percentage of CPU usage that triggers scaling
* **Min Replicas:** Minimum number of backend pods to maintain
* **Max Replicas:** Maximum number of instances the autoscaler can create
Important Considerations
* Setting min replicas too low may cause cold start delays during traffic spikes
* Setting max replicas too high could lead to unnecessary costs
* Monitor your typical traffic patterns to optimize these settings
### Deno Resources
The **Deno** pod handles execution of your [Lambda Functions](/the-function-stack/functions/apis-and-lambdas/lambda-functions)
**Configuration Options:**
* **Requested CPU:** Minimum CPU allocation
* **Limit CPU:** Maximum CPU the backend can consume
* **Requested RAM:** Minimum memory allocation
* **Limit RAM:** Maximum memory the backend can use
### Node Resources
**Node** powers our realtime functionality as well as certain core functionality of your Xano instance such as team collaboration and state mangement
**Configuration Options:**
* **Requested CPU:** Base CPU allocation (e.g., 5m)
* **Limit CPU:** Maximum CPU available (e.g., 500m = 0.5 CPU cores)
* **Requested/Limit RAM:** Memory allocation (e.g., 2048Mi = 2 GB)
### Database Resources
This section may not be present if your database is offloaded to a managed service, such as CloudSQL.
**Database pod** manages your PostgreSQL database pod and handles all database operations.
While you do have a separate backend pod for business logic, it's important to note when workloads will lean on the database resources. If an API executes a Query All Records function, the backend is only responsible for passing that instruction to the database, and receiving the result when it's ready. The database resources are used to actually perform the operation.
**Configuration Options:**
* **Requested CPU:** Guaranteed database CPU (e.g., 5m)
* **Limit CPU:** Maximum database CPU (e.g., 2000m = 2 CPU cores)
* **Requested/Limit RAM:** Database memory allocation
* **Storage:** Persistent storage for your database (measured in Gi = Gibibytes, e.g., 10Gi ≈ 10.7 GB)
Optimization Tips
* Database performance heavily depends on RAM for caching
* Consider your data size and query complexity when setting limits
* Storage should account for data growth over time, and should never reach over 50% - 60% capacity for best performance.
### Task Resources
**Task resources** execute [Background Tasks](/building/logic/background-tasks). Please note that these resources are for all of your tasks collectively, and not individual tasks.
**Configuration Options:**
* **Requested CPU:** Minimum CPU allocation
* **Limit CPU:** Maximum CPU your tasks can consume
* **Requested RAM:** Minimum memory allocation
* **Limit RAM:** Maximum memory your tasks can use
**When to Scale Up:**
* High volume of background jobs
* Complex data processing tasks
* Frequent scheduled operations
### Frontend Resources
**Frontend service** serves your Xano interface
**Configuration Options:**
* **Requested CPU:** Often minimal (0m for light loads)
* **Limit CPU:** Usually 50m-100m is sufficient
* **RAM:** Typically 16Mi-32Mi for basic serving
It's not likely that this will ever require adjustment.
### Global Redis Resources
This section may not be present if Redis is offloaded to a managed service such as Memorystore within GCP.
**Redis cache** powers all of the high-performance caching functions and response caching
**Configuration Options:**
* **CPU:** Usually 5m-1000m depending on cache usage
* **RAM:** Critical for Redis performance (384Mi-512Mi typical)
* **Storage:** Persistent storage for Redis data
Redis-Specific Warnings
* Redis is memory-intensive; insufficient RAM will impact performance significantly
* Storage ensures data persistence across pod restarts
## Additional Information
# Security Policy
Source: https://docs.xano.com/enterprise/enterprise-features/security-policy
## What is Security Policy?
This panel as a part of your instance settings enables certain security measures that you might need to ensure data integrity / safety, or for compliance reasons. This can include things like enforcing inactivity logout, authentication services, 2FA, or SSO.
You can access the Security Policy panel by heading to your [instance selection screen](https://app.xano.com/instance), clicking the⚙️ icon next to your instance, and choosing Security Policy from the panel that opens.
Accessing the Security Policy panel
## For All Paid Plans
Certain security policy settings are available for all paid Xano plans, and include the following:
### Allow Direct Query
This setting determines whether or not use of the [Direct Database Query](/the-function-stack/functions/database-requests/direct-database-query) function is allowed in your function stacks.
## **Why would you want to disable Direct Query?**
Direct Query enables you to not only run basic database functions, such as adding or updating data, but also enables access to more advanced and potentially dangerous SQL statements. Disabling this function helps ensure that team members can't execute functions that they shouldn't be.
### Redis Key Isolation
This setting determines whether or not keys you set using [caching functions](/the-function-stack/functions/data-caching-redis) are available in other workspaces.
## **Why enable Redis Key Isolation?**
This can be especially important if you have different team members who have access to different, isolated workspaces. Key Isolation helps ensure that in the rare case separate teams use the same keys that there isn't a conflict.
## Premium Features
These features are only available via a premium add-on as a part of our Enterprise or Custom plans. Contact your Xano representative to learn more.
### **Inactivity Logout Time**
This setting enables automatic logout of Xano due to inactivity for all team members. If enabled options range between 1 to 24 hours.
### **Require 2FA**
This setting enforces all team members of your Instance to authenticate using 2FA when logging into Xano.
### **Authentication Enforcement**
This setting optionally enforces which authentication service(s) team members can authenticate with.
### **Allowed SSO Hosts**
This setting enforces the email address domains allowed when team members log in. For example, if we wanted team members to only authenticate using Github accounts that use a xano.com email address, we would check Github under Authentication Enforcement and add xano.com as an allowed SSO host.
### **IP Address Allowlist**
This setting enforces certain IPs allowed to access your Xano instance and call your APIs
### **IP Address Denylist**
This setting enforces denying IPs allowed to access your Xano instance and call your APIs
# Tenant Center
Source: https://docs.xano.com/enterprise/enterprise-features/tenant-center
## **Quick Summary**
The Tenant Center allows you to deploy your current workspace to multiple tenant environments. Tenants are best utilized for things like separate development, staging, and production environments, or isolating different customers or user groups into their own workspaces, like users in a specific region or your beta testers.
Each tenant gets its own isolated database, and receives logic from releases you choose to deploy.
What Tenant Center unlocks and when to reach for it
The end-to-end flow: create a tenant, deploy a release, call its APIs
Day-2 operations: edit, impersonate, env vars, backups, logs
Shared, Dedicated, and Remote namespaces, plus infrastructure sizing
Register remote Kubernetes clusters for Regional Isolation tenants
Permissions and common role recipes
## Why Tenant Center
The Tenant Center brings a traditional CI/CD workflow into Xano, and gives you a single place to run as many isolated copies of your backend as your business needs — each with its own database, its own URL, and its own lifecycle.
With Tenant Center, you can:
* **Run real dev / stage / production environments** for the same workspace, instead of editing live and hoping for the best
* **Isolate customers or user groups** into their own tenants — perfect for per-customer data isolation, beta cohorts, or rolling out new features to one group at a time
* **Deploy across regions** to reduce latency for users in another part of the world or to satisfy data-residency requirements
* **Stage Xano platform upgrades safely** by running a tenant on a newer (or older) platform release and validating against it before rolling that version out everywhere else
Higher tenant tiers extend this further: a Dedicated tenant gets its own CPU, memory, and storage so it's insulated from noisy neighbors and can be sized to its workload, and a Remote tenant runs on infrastructure in a specific region or cluster you control. See [Tenant Types](#tenant-types) for the full breakdown.
### Tenant vs. branch vs. workspace
| Use a... | When you need... |
| ------------- | -------------------------------------------------------------------------------------------------- |
| **Branch** | An isolated edit state inside the same workspace for a feature or experiment. No separate runtime. |
| **Tenant** | An isolated runtime with its own database and URL, sharing logic released from a source workspace. |
| **Workspace** | A fully separate project with its own branches, releases, and tenants. |
## Using Tenant Center
This section walks the full Tenant Center flow in the order you'll actually use it: create a tenant, call its APIs, and deploy a release to it.
### Creating New Tenants
You'll find it located under the Marketplace (if you have it enabled) or the Library.
Click Add Tenant to create a new tenant.
Remember, tenants can be either your own stage and production environments, or actual separate user workspaces.
When adding a new tenant, you'll need to provide some basic information.
| Parameter | Purpose | Example |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Display Name | The name of the tenant workspace | Stage, Beta, Customer ABC |
| Description | A description of the tenant workspace | "Staging changes for testing" "Workspace for customer ABC" "Beta access" |
| Type | See [Tenant Types](#tenant-types) | |
| Platform | Choose which Xano release you want your Tenant to deploy with. | The latest release is recommended. |
| Cluster | See [Tenant Clusters](#tenant-clusters) | |
| RBAC Override | Enable this option to set specific user permissions for this tenant. See the [RBAC: Tenant Center](#rbac-tenant-center) section below for more information. | |
| Ingress Enabled | Enable or disable ingress (incoming traffic) for this tenant. Disabling ingress will prevent any API calls from reaching this tenant. Use this if traffic is routed through your own gateway/load balancer instead of Xano's default ingress. | |
| Tags | Apply tags to your tenants to easily filter them when searching and deploying new changes. Great for things like separating subscription tiers or tagging development-specific, internal tenants. **This is optional, but highly recommended** | dev prod beta |
| Custom Domain | Custom domains require additional setup outside of Xano. Please reach out to support for more details. | |
## **A note on new tenant creation**
Creating a new tenant does not deploy a release to it by default.
### Developing and Deploying Releases
Once you have one or more tenants, you push changes to them by cutting a **release** from your source workspace and deploying it. A release is a snapshot of **logic and schema only** — no data — taken from a source branch. Deploying a release to a tenant overwrites its function stacks, APIs, and table structure, but **preserves**:
* Tenant database records
* Environment variables
* Backups
* RBAC overrides
* Ingress and infrastructure settings
**Worth a quick read: "release" and "platform" are two different things in Xano.**
A **release** (what this section is about) is a snapshot of *your* workspace logic and schema that you deploy to tenants. A tenant's **platform** is the version of Xano itself that tenant is running, chosen via the **Platform** setting when you create the tenant.
The two are completely independent — updating a tenant's platform won't deploy your workspace changes, and deploying a release won't change the platform a tenant is running on.
### Preventing Deployment issues
#### Backups
Backups are available for your tenants by clicking the and selecting **Backups**. Create a backup by selecting Create New Backup.
Backups are designed to be retained long term, and can be downloaded for offline archival. They contain the entirety of the tenant: database and logic.
#### Snapshots
Snapshots are similar to backups, but designed specifically to **only retain the database** for quick rollback after a deployment, should it be necessary.
Snapshots are available for your tenants by clicking the and selecting **Snapshots**. Create a snapshot by selecting Create New Snapshot.
Snapshots are not written back to the tenant -- the tenant is 'swapped' to that snapshot if you choose to do so, retaining the live database, so you can swap back at any time.
You can also manage snapshots from the CLI with `xano tenant snapshot create`, `list`, `swap`, and `delete`. See [Tenant Snapshots in the CLI docs](/xano-cli/tenants#tenant-snapshots).
\*\* Active connections will be briefly dropped \*\*
To clone the database, the tenant's live connections are terminated for a few seconds while the copy runs. You'll need to check the box to agree to this before continuing.
Just make sure you're deploying from the tenant that contains your final, tested round of changes to push live to your tenants.
Select the appropriate tags and click **Apply**. Remember, you can also deploy to a single tenant by clicking the icon on that specific tenant.
Click Releases at the top of the page to open the Releases panel.
In the Releases panel, click Add New Release
Give your new release a name, a description, and choose the source branch you'll be deploying changes from.
When you're ready, click Create at the bottom of the panel.
You can click the checkbox at the top to select all currently shown tenants, or select individual tenants yourself.
When deploying to multiple tenants, deployment runs sequentially. If a tenant fails (for example, an invalid database reference), the deploy stops on that tenant and remaining tenants are skipped — resolve the failure and re-run the deploy against the remaining tenants.
Click at the top of the page to deploy a release to your selected tenants.
Select the release to deploy and click the Deploy button at the bottom of the panel.
After deployment, the **Release Stats** table at the top will give you quick visibility into your deployment metrics.
### Calling Tenant APIs
Each tenant will have their own base URL, which can be used to call a tenant's APIs directly. You can find this URL and more by clicking and choosing Details.
You can also utilize the `X-Tenant` header to route a request to a specific tenant instead of using that tenant's base URL. Set the header as `X-Tenant: ` against your source workspace's base URL and the request will be routed to that tenant. This is useful when a single frontend needs to target multiple tenants without swapping base URLs.
## Managing Tenants
Once you've created a tenant, you can click the ⋮ icon to access tenant settings.
### Edit Tenant
Change the settings applied when creating the tenant, such as the display name or description.
| Option | Description |
| ---------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Display Name | Change the human readable name of the tenant |
| Description | Edit the tenant description |
| Enable [RBAC Override](#rbac-override) | Allows for tenant-specific RBAC configuration |
| Add or Edit Tags | Use tags for easily searching for related items in your workspace |
| Custom Domain | Add a custom domain (contact support for setup information) |
| Proxy URL | Forward all requests to a different URL |
### Deploy Release
Push a release (a snapshot of your workspace logic and schema) to this specific tenant. This is the same flow described in [Developing and Deploying Releases](#developing-and-deploying-releases), scoped to a single tenant.
When you open the panel you'll see:
* **Release selector** — choose any release from the source workspace. Each entry shows the release name, hotfix label (if any), and the timestamp it was created.
* **View Changes** — opens a diff of the current tenant content versus the selected release so you can review exactly what will change before deploying. If the tenant is already on the selected release, this option is disabled.
* **Deploy** — runs the deployment. The panel reports per-tenant progress and elapsed time.
A few behaviors worth knowing:
* If a release references a database object (table, field, etc.) that doesn't exist on the target tenant, the deploy fails with a database reference error and the tenant is left on its previous release. Resolve the missing reference and re-run the deploy.
* You can deploy to multiple tenants in one operation from the main Tenant Center view; deployment runs sequentially and stops on the first failure.
* Deploy Release does **not** change the tenant's platform version — for that, use Deploy Platform below.
### Deploy Platform
Update the **Xano platform version** this tenant runs on. This is independent of Deploy Release: a release ships *your* workspace logic, while Deploy Platform updates the underlying Xano runtime the tenant executes against.
The panel shows:
* **Platform selector** — choose any available Xano platform version. Each entry shows the platform ID, name, and the date it was published. The selector defaults to the tenant's current platform.
* **Deploy** — applies the selected platform to the tenant.
While the platform deploy is running you'll see *"Your tenant is being updated. This may take a few minutes."* — the tenant's pods are recreated against the new platform image, so expect a brief restart of the affected services.
Use Deploy Platform to:
* Stage a tenant on a newer platform version to validate your workspace against it before rolling that version out to production tenants
* Pin a tenant to a specific platform version for stability
* Catch a tenant up to the platform other tenants are already running
Deploy Platform is available on Resource Isolation (Dedicated) and Regional Isolation (Remote) tenants. Shared Namespace tenants run on the same platform as the source instance and don't expose this option.
### Manage Resources
Edit the CPU, memory, storage, autoscaling, affinity, and toleration settings for this tenant's deployments. Available on Resource Isolation and Regional Isolation tenants.
This panel is covered in detail in [Configuring Resources for Tenants](#configuring-resources-for-tenants), including the Small / Medium / Large templates, the Custom editor, per-deployment configuration for the database and Redis instances, the Horizontal Pod Autoscaler fields, and how affinity and toleration rules interact.
Two save options are available at the bottom of the panel:
* **Save** — persists your resource changes without redeploying the tenant's platform.
* **Save & Deploy** — persists the changes and immediately redeploys the platform so the new resource allocation takes effect. If the tenant has no platform assigned yet, only Save is available.
### Infrastructure
A read-only observability view into the live Kubernetes resources backing this tenant. Use it to check pod health, verify a deployment rolled out correctly, look up the tenant's external IP, or confirm storage is provisioned.
The panel is organized into six tabs, each backed by live data from the cluster. A **Refresh** button at the top reloads the current tab.
| Tab | What it shows |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pods** | Every running pod with current CPU usage, RAM usage, age, restart count, lifecycle phase, and ready status. Click a row to see container images, ports, resource requests/limits, and status history. |
| **Deployments** | Each deployment with ready vs. desired replica counts and the container image being used. Click through for full container specs. |
| **Services** | Service discovery details: service type (ClusterIP, LoadBalancer, etc.), cluster IPs, external IP, and exposed ports. Useful for tracing how traffic reaches the tenant. |
| **PVCs** | Persistent Volume Claims: name, status, capacity, access modes, storage class, and age. This is where you confirm the database's persistent storage is healthy. |
| **Ingress** | Ingress configuration: ingress class, hostnames, and the load balancer address or IP that external traffic enters through. |
| **Jobs** | Kubernetes Jobs associated with the tenant: name, start time, age, completion count, and success count. |
CPU is reported in cores or millicores (e.g. `1.2 cores` or `850m`) and memory in Gi or Mi depending on magnitude.
The Infrastructure panel is read-only — to change any of these values, use [Manage Resources](#manage-resources) or [Deploy Platform](#deploy-platform).
### Impersonate
Access the tenant in its current state. Great for troubleshooting tenant-specific issues and manual verification of pushed changes
### Environment Variables
You can access and manage this tenant's environment variables from here. Use these to store things like API keys and other sensitive information to be used in that tenant's function stacks.
For example, if you are pushing a feature that calls OpenAI, and each tenant has their own OpenAI API key, you'd put that here and just make sure the variable name matches what your function stacks reference.
### Backups
Create or restore a backup of a tenant
### Logs
Review logs directly associated with that tenant, such as release deployments, backups, and impersonations.
***
## Tenant Types
Some workspaces may have access to different tenant types, which unlock significant operational flexibility beyond the default Shared Namespace. Upgrading to a Dedicated or Remote tenant lets you:
* **Choose dedicated CPU, memory, and storage** so a tenant is insulated from noisy neighbors and can be sized to its actual workload
* **Pin a tenant to a specific region** for data residency compliance or to reduce latency for users in that region
* **Run a tenant on a specific Xano platform release**, which is invaluable for safe development — you can stage a tenant on a newer or older platform version and validate your workspace against it before rolling that platform version out to production tenants
When creating a new tenant, you may see a **Type** dropdown. This allows you to select which tenant type to assign to the new tenant.
### What's available at each tier
| Capability | Data Isolation (Shared) | Resource Isolation (Dedicated) | Regional Isolation (Remote) |
| ----------------------------------------------------------- | ----------------------- | ------------------------------ | --------------------------- |
| Isolated database and base URL | ✓ | ✓ | ✓ |
| Deploy releases from a source workspace | ✓ | ✓ | ✓ |
| Per-tenant environment variables, backups, and impersonate | ✓ | ✓ | ✓ |
| Dedicated CPU, RAM, and storage (no noisy-neighbor effects) | — | ✓ | ✓ |
| Configurable Horizontal Pod Autoscaler | — | ✓ | ✓ |
| Pin to a specific Xano platform version (Deploy Platform) | — | ✓ | ✓ |
| Live infrastructure observability (pods, PVCs, ingress…) | — | ✓ | ✓ |
| Run in a specific region or your own Kubernetes cluster | — | — | ✓ |
| Data residency for compliance use cases | — | — | ✓ |
Shared tenants are the right starting point when isolation between customers is the only goal and your workloads can safely share resources. Dedicated tenants add control over the infrastructure each tenant runs on — sizing, autoscaling, platform version, and live observability — which is what you need once a tenant has SLAs, predictable load requirements, or has to be staged on a specific Xano version. Regional tenants extend that further by running on infrastructure in a region or cluster you control, which is the only option that satisfies data-residency requirements or in-region latency targets.
| Type | Description | Pick this when |
| ---------------------------------------- | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Data Isolation (Shared Namespace) | Shares resources with the source instance. No extra settings. | You need data isolation between customers but the workloads can safely share resources. Lowest overhead. |
| Resource Isolation (Dedicated Namespace) | Gets dedicated resources; you choose allocation after creation. | A tenant has predictable load requirements, SLAs, or noisy-neighbor concerns. |
| Regional Isolation (Remote Namespace) | Runs on dedicated resources in a different cluster/region. | You have data residency requirements or need to reduce latency for users in another region. |
Tenant type is set at creation and cannot be changed afterward. To move a tenant to a different type, create a new tenant at the desired type and migrate data via backup/restore.
### Tenant Infrastructure
When deploying a *Resource Isolation (Dedicated Namespace)* or *Regional Isolation (Remote Namespace)* tenant, after creating the tenant you'll be prompted to select the specific infrastructure allocation for that tenant. We offer three pre-defined infrastructure packages, plus a Custom option:
* Small = “Get me live fast.”
Best for MVPs, prototypes, internal tools, early-stage production, or moderate traffic.
* Medium = “We’re in production and growing.”
For apps with steady real users, more endpoints, more background jobs, and higher concurrency.
* Large = “We need serious headroom.”
Built for high traffic, enterprise workloads, heavy automation, larger datasets, and lots of simultaneous users.
* Custom = manually define all aspects of a tenant's available resources for more advanced configurations.
### Configuring Resources for Tenants
**Resource Isolation** and **Regional Isolation** tenants both run on dedicated infrastructure, which means you control exactly how much CPU, memory, storage, and scaling capacity is allocated to each deployment. After a qualified tenant is created, open its **⋮** menu and choose **Manage Resources** to open the resource configuration panel.
#### Templates vs Custom
At the top of the panel you'll see four options: **Small**, **Medium**, **Large**, and **Custom**.
* Clicking **Small / Medium / Large** applies one of the predefined infrastructure packages described above — a quick starting point for most tenants.
* Any time you change an individual value, the selection automatically switches to **Custom**, indicating that you've diverged from a template. You can return to a template at any point by re-selecting it (this will overwrite your custom values).
* Toggling **Verbose** at the top reveals additional detail in the summary view, including affinity and toleration rules.
#### Deployments
A tenant with configurable resources is made up of two independently configurable deployments:
* **Database** — the tenant's Postgres instance, including persistent storage
* **Redis** — the tenant's Redis instance, used for caching and realtime features
Each deployment can be toggled **ON** or **OFF** using the colored buttons near the top of the panel. Disabling a deployment frees its resources but will disable any tenant functionality that depends on it, so only turn these off if you're sure your tenant doesn't need them.
Click the edit (pencil) icon on a deployment to configure its resources.
#### CPU and RAM
For each deployment you can configure four values:
| Field | Purpose |
| ------------- | ------------------------------------------------------ |
| Requested CPU | The minimum CPU Kubernetes guarantees to the container |
| Limit CPU | The maximum CPU the container is allowed to consume |
| Requested RAM | The minimum memory guaranteed to the container |
| Limit RAM | The maximum memory the container is allowed to consume |
Requested values reserve capacity on the node; limits cap burst usage. As a rule of thumb, set requests to what the workload normally needs and limits to a safe ceiling above that. Setting requests equal to limits gives you the most predictable performance.
#### Autoscaler (Horizontal Pod Autoscaler)
Deployments that support autoscaling expose an **Autoscaler** section with three fields:
| Field | Purpose |
| ------------- | -------------------------------------------------------- |
| Min replicas | Minimum number of pods to keep running at all times |
| Max replicas | Maximum number of pods the autoscaler can scale up to |
| CPU threshold | Target CPU utilization percentage that triggers scale-up |
When average CPU across running pods exceeds the threshold, Kubernetes adds replicas (up to **Max**). When utilization drops, it scales back down (no lower than **Min**). Increase **Min replicas** for workloads that need hot capacity on standby; increase **Max replicas** to give the tenant more headroom for traffic spikes.
#### Storage
For deployments with persistent storage (the database), set the **Storage** value to the size of the persistent volume. Storage can typically be increased later but not decreased, so start conservatively and grow as needed.
#### Affinity
**Affinity** rules control which nodes in the cluster your tenant's pods are allowed to run on. This is especially useful on Regional Isolation clusters where you've tagged nodes by zone, hardware class, or customer. Each expression consists of:
* **Key** — the node label to match (e.g. `topology.kubernetes.io/zone`)
* **Operator** — `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`
* **Value** — the value (or values) to match against
* **Type** — `Required` (hard constraint; pods won't schedule without a match) or `Preferred` (soft constraint; scheduler tries but will fall back)
Click **Add Affinity...** to add additional expressions. All expressions are combined to select eligible nodes.
#### Toleration
**Tolerations** let tenant pods run on nodes that have been tainted — for example, nodes reserved for a specific customer or workload class. Each toleration consists of:
* **Key** — the taint key on the node
* **Value** — the taint value (when applicable)
* **Operator** — `Equal` or `Exists`
* **Effect** — `NoSchedule`, `PreferNoSchedule`, or `NoExecute`
Tolerations don't *require* the pod to run on tainted nodes — they just allow it to. Combine tolerations with affinity rules when you need to both allow and require placement on specific nodes.
#### Saving changes
When you're finished, click **Ok** to close the edit view for a deployment, then **Save & Deploy** (or **Deploy** if you arrived from another flow) at the bottom of the panel. Resource changes are rolled out immediately, which may cause a brief restart of the affected deployment.
## Tenant Clusters
A **Tenant Cluster** is a remote Kubernetes cluster registered with your instance and used to host **Regional Isolation** tenants (the *Remote Namespace* type). Tenant Clusters are what make it possible for a tenant created in the Tenant Center to run in a different region, a dedicated production environment, or any other Kubernetes footprint you control.
Typical use cases:
* Hosting tenants in a specific geographic region for latency or data-residency requirements
* Running isolated production environments separate from your main instance
* Dedicating infrastructure to a particular customer or customer segment
Tenant Clusters are managed from the Tenant Clusters panel (available on plans that include Regional Isolation). Once a cluster is registered, it becomes a selectable target when you create a Regional Isolation tenant in the Tenant Center.
### Creating a Tenant Cluster
From the Tenant Clusters panel, click **Add new cluster** and provide:
| Field | Purpose |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cluster Name | Display name used when selecting the cluster during tenant creation |
| Description | Optional notes about the cluster's purpose |
| Type | **Standard** for on-demand tenants, or **Run** to keep a pool of pre-provisioned ("warm") tenants ready for fast assignment |
| Warm Tenants by Template | *(Run type only)* Number of warm tenants to keep on deck for each template size: Small, Medium, Large, and Custom |
| Domain | Base domain for the cluster. Each tenant deployed to this cluster will be a subdomain of this domain by default (per-tenant custom domains are still supported) |
| Ingress Settings | *(Optional)* Xano Secret, Xano TLS Host, Custom Secret, Custom TLS Host, and YAML Annotations for the ingress controller. Tenant variables such as `{{tenant.name}}.domain.com` can be used in any field |
| Credentials (KubeConfig) | The KubeConfig YAML used to authenticate against the target cluster *(see below)* |
### KubeConfig
The **Credentials** field accepts a standard Kubernetes `kubeconfig` YAML document — the same file format produced by `kubectl config view --raw` or by your cloud provider's CLI (e.g. `aws eks update-kubeconfig`, `gcloud container clusters get-credentials`, `az aks get-credentials`).
Xano uses this KubeConfig to connect to your cluster and provision, update, and remove tenant workloads. A few things to keep in mind:
* **Required permissions** — the credentials must have sufficient RBAC permissions in the target cluster to create and manage namespaces, deployments, services, ingresses, and secrets.
* **Network reachability** — the cluster's API server must be reachable from Xano. If your control plane is behind an IP allow-list, make sure Xano's outbound IPs are whitelisted before saving the KubeConfig.
* **Long-lived credentials** — prefer service-account tokens or other long-lived credentials over short-lived user tokens, since Xano needs ongoing access to manage tenants over the cluster's lifetime.
* **Updating credentials** — you can rotate the KubeConfig at any time by opening the cluster, clicking **Credentials**, and pasting the new YAML. This requires the `TenantClusterSecrets: Update` permission.
The KubeConfig grants Xano administrative access to the target cluster. Store and rotate it with the same care you'd apply to any other cluster admin credential.
### Editing and Deleting Clusters
Opening a cluster from the list shows its general settings and ingress configuration. From here you can:
* **Edit** general settings — name, description, type, warm pool sizes, and domain
* **Edit Ingress** — update ingress secrets, TLS hosts, and annotations independently of the general settings
* **Credentials** — view or replace the cluster's KubeConfig
* **Delete** — remove the cluster registration. Deletion requires typing a confirmation phrase and cannot be undone
### How Tenant Clusters relate to the Tenant Center
Tenant Clusters are the infrastructure layer; the Tenant Center is where you create and operate the tenants that run on them. The flow is:
1. **Register a cluster** in Tenant Clusters by supplying its KubeConfig, domain, and ingress settings.
2. **Create a tenant** in the Tenant Center and choose **Regional Isolation** (*Remote Namespace*) as the type.
3. **Select the cluster** you registered as the target for that tenant.
4. **Deploy releases** to the tenant from the Tenant Center exactly as you would for any other tenant — the release is deployed into the remote cluster transparently.
If you're using a **Run**-type cluster with warm tenants configured, new tenant creation pulls from the warm pool for near-instant provisioning; Xano then replenishes the pool in the background.
### Permissions
Tenant Cluster management is gated by dedicated RBAC permissions:
* **TenantCluster** — Create, Read, Update, Delete cluster registrations
* **TenantClusterSecrets** — Read and Update the KubeConfig credentials stored on a cluster
## RBAC: Tenant Center
The Tenant Center addon includes additional [Role-based Access Control (RBAC)](/team-collaboration/role-based-access-control-rbac) settings you can use to manage tenant-related permissions.
These permissions include:
* **Tenant Center** - Enables access to the Tenant Center
* **Tenant Center RBAC** - Enables access to Tenant Center RBAC Override settings *Note: This does not disable the ability to disable/enable Tenant Center RBAC Overrides, but does disable access to editing the specific override settings.*
* **Tenant Center Logs** - Enables access to the logs inside of the Tenant Center
* **Tenant Center Backup** - Determines if a user can modify backup settings or perform backup/restore operations for tenants
* **Tenant Center Deploy** - Determines if a user can deploy releases to tenants
* **Tenant Center Impersonate** - Determines if a user can impersonate (access directly) a tenant
* **Tenant Center Secrets** - Enables access to secrets for a tenant, such as [Environment Variables](/the-function-stack/environment-variables)
### RBAC Override
From the **Edit Tenant** panel, you can enable **RBAC Override**. This option allows you to specify individual user permissions for each tenant by clicking **RBAC** at the top of the Tenant Center.
### Common role recipes
| Role | Permissions to grant |
| ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| **Deploy operator** — can ship releases but not change tenant config or read secrets | Tenant Center, Tenant Center Deploy, Tenant Center Logs |
| **Read-only auditor** — can review tenant state and deploy history without making changes | Tenant Center, Tenant Center Logs |
| **Tenant admin** — full lifecycle ownership of a tenant including secrets and backups | Tenant Center, Tenant Center Deploy, Tenant Center Backup, Tenant Center Secrets, Tenant Center Impersonate, Tenant Center Logs |
| **Support engineer** — can impersonate to troubleshoot but cannot deploy or change secrets | Tenant Center, Tenant Center Impersonate, Tenant Center Logs |
## Best Practices
Using tags is crucial to quick and consistent work inside of the Tenant Center, especially as the number of tenants you have grows.
This would include developing on a **development** tenant, pushing final changes to a **stage** tenant where all of your [QA and testing](/testing-debugging/test-suites) happens, and then deploying releases from **stage**.
Read more about the entire Development Lifecycle [here](/before-you-begin/the-development-life-cycle).
In most cases, it's good practice to make sure your users are aware of upcoming changes.
# Xano Link
Source: https://docs.xano.com/enterprise/enterprise-features/xano-link
The Xano Link feature is an additional add-on. Please contact your Xano representative or support for details.
### What is Single-Tenancy vs Multi-Tenancy
Single-tenancy means that a user is on their own dedicated server environment. Their data is completely separated and isolated from any other user. A multi-tenancy environment means users share the same server resources across a shared environment.
### How Xano Link Works
Xano Link is a feature that allows you to use a separate workspace for each client (aka tenant). Each workspace is a separate environment with its own copy of all schema, which includes the database, API, Addons, Functions, and Background Tasks. This allows for a single-tenant solution to be built on Xano.
Xano Link still shares the same Instance server resources across all tenants, so Link is not a true form of single-tenancy. However, it is a similar solution through data separation and workspace isolation.
Xano Link provides the Instance owner an interface where they can publish one source workspace to many client workspaces. Changes or updates can be made to the source workspace and published to many client workspaces. This is a manual process so it requires keeping track of which client workspaces need to be updated. It is recommended to use naming conventions for the workspaces to help keep track (e.g. product\_name:source, product\_name:user\_id).
Xano Link can be accessed from the settings of the source workspace.
Once inside, you can choose to Link APIs, functions, addons, and database tables. Take note of the **Select All/None** and **Auto include dependencies** options to assist in ensuring that the Link only merges the data you want. You also have the option to include records from the selected database tables, or only merge the schema.
**Select All/None** allows you to quickly bulk select or de-select items.
**Auto include dependencies** will scan and auto-include in the Link any items that are dependent on what you have already selected. For example, if you are choosing API endpoints that include custom functions, the functions will also be merged without you having to select them manually.
### Merging Database Tables
You have the option to choose specific tables and records to merge when using Xano Link. Click on the record count to select specifically which records you want to merge, or select all.
When you use Xano Link to merge database tables, and the destination workspace already has that table created, you will need to change the GUID of the destination table to match, otherwise you will have duplicate tables. The steps below will outline how to change the GUID. Please proceed with caution as you change these advanced settings.
1. Head to the **source table**, click the three dots in the top-right, and choose Security.
2. Copy the GUID that is shown.
3. After you've copied the GUID, head to the **destination table** in the new workspace, and replace the GUID with the copied value from the source table and save your changes.
Once you're ready to publish an update select which client workspaces the update should be pushed to. You also have the option to merge the newly created branch with whatever branch in the target workspace is set to live, and / or set the newly created branch as the live branch.
**Merge New Branch with existing Live Branch** will merge the newly created branch with the branch in the destination workspace that is currently set to live.
**Set New Branch Live** will set the newly created branch as the live branch immediately.
#### Customization
Customization on a per-client basis is possible by using **additional** tables or APIs that are independent of the source workspace. Customization to the schema from the source workspace would get overwritten with any new updates.
### Compare Differences
Xano Link allows you to view and compare differences before merging a branch from the source workspace into a branch from the destination workspace.
Be sure to select the Merge New Branch option and the destination workspace before selecting "view.
By selecting view, you can see which items contain differences.
By selecting "changes" next to an item, you can see a snapshot of the differences.
# Xano For Enterprise (Custom Plans)
Source: https://docs.xano.com/enterprise/xano-for-enterprise
## Why choose a Custom plan?
Deploy Xano within your own internal infrastructure
* Complete isolation
* Strict security protocols
Multi-zone deployment designed for critical production applications
* Dynamically adjusts compute resources based on application traffic patterns and usage metrics.
* Pre-built integrations with common CRM and CDP systems enable unified data management across platforms.
* Supports custom SSO implementation and policy enforcement for organizational authentication standards.
* 24/7 emergency support for service outages
* Proactive health and release monitoring
* Database migration assistance
* Technical consultation services with a Solutions Engineer
* 24/7 emergency support for service outages
* Proactive health and release monitoring
* Database migration assistance
* Technical consultation services
## What's possible with Xano's Custom plan?
Xano's standard plans are designed to meet a wide range of application development needs.
However, organizations with more complex requirements find that Xano for Enterprise offers the advanced capabilities and dedicated support necessary for large-scale projects and demanding environments.
## Key Capabilities of the Xano Custom plan
### Flexible Infrastructure Options
**Bring Your Own Cloud (BYOC) Deployment**
Xano Enterprise allows you to deploy your Xano instances within your preferred cloud provider (AWS, Azure, or Google Cloud). This provides significant advantages in terms of:
* **Data Sovereignty:** Maintain direct control over the location and governance of your data.
* **Regional Compliance:** Deploy in specific geographic regions to meet regulatory requirements.
* **Custom Resource Allocation:** Tailor your infrastructure resources to optimize performance and cost.
* **Granular Access Control:** Manage team permissions and access to resources through Role-Based Access Control (RBAC).
* **Scalable Architecture:** Deploy multiple instances within a single cloud account to support growing application demands.
**On-Premise Deployment Option**
For organizations with stringent security and compliance needs, Xano for Enterprise can be deployed within your own internal infrastructure, offering a completely isolated environment.
**High Availability Configuration for Critical Applications**
Ensure the continuous operation of your most important applications with our multi-zone deployment architecture, featuring:
* **Redundancy:** Eliminate single points of failure to maximize uptime.
* **Data Protection:** Implement cross-zone data backups for disaster recovery.
* **Automated Recovery:** Benefit from automatic failover mechanisms to maintain service continuity.
* **Service Level Agreement (SLA) Support:** Meet your organization's defined uptime requirements.
## **Performance and Scalability Features**
**Dynamic Resource Management with Auto-Scaling**
Xano for Enterprise automatically adjusts compute resources based on your application's traffic patterns and usage, ensuring optimal performance without manual intervention.
**Robust Database Architecture**
* **Direct PostgreSQL Access:** Facilitates integration with external systems and provides greater control over your data.
* **Horizontal Scaling Capabilities:** Enables your database to handle high volumes of queries and data across multiple regions.
## **Platform Integration and Extensibility**
**Seamless Integration with Enterprise Systems**
Our connector system provides pre-built integrations with popular CRM and CDP platforms, streamlining data management across your organization.
**Microservice Integration**
Xano for Enterprise allows you to host and manage third-party microservices within our infrastructure, providing isolation and efficient resource allocation. This enables integration with your existing technology stack and enables extending the functionality of not only your Xano environment, but also allows for seamlessly integrating legacy systems and code.
**Enhanced Identity Management**
Supports the implementation of custom Single Sign-On (SSO) and the enforcement of organizational authentication policies for secure access.
**Comprehensive Development Environment Management**
* **Multiple Environment Support:** Manage your application lifecycle effectively with dedicated environments for development, testing, staging, and production.
* **API Branching and Documentation:** Enables parallel development efforts with automated API documentation for each branch.
* **Flexible Database Configuration:** Connect to different database sources for various development stages.
**Advanced Monitoring and Control**
* **Detailed API Request Logging:** Provides enhanced visibility into application usage with customizable log retention policies.
* **Resource Usage Tracking and Optimization:** Offers tools to monitor and optimize resource consumption for cost efficiency.
* **Private Function Marketplace:** Allows organizations to create and share standardized functions for consistent development practices.
## **Security and Compliance**
**Comprehensive Access Control Mechanisms**
* **Role-Based Access Control (RBAC):** Enables fine-grained control over user permissions and access to resources.
* **Team Collaboration Features:** Facilitates secure collaboration among development teams.
* **Customizable Security Policies:** Allows the enforcement of organizational security standards, including inactivity timeouts, two-factor authentication (2FA), and SSO.
**Infrastructure Security Measures**
* **DDoS Protection:** Integrated Cloud Armor protection against distributed denial-of-service attacks.
* **Enhanced Security Testing:** Regular and rigorous penetration testing protocols to identify and address potential vulnerabilities.
* **Regular Security Audits:** Independent security audits to ensure adherence to industry best practices.
#### **Commitment to Compliance Standards**
Xano for Enterprise is designed to help organizations meet various regulatory and industry compliance standards, including:
* **HIPAA Compliance:** With the availability of a Business Associate Agreement (BAA).
* **GDPR Compliance:** Supported through a Data Processing Agreement (DPA).
* **SOC 2 Type 2 & SOC 3 Certification:** Demonstrating our commitment to security, availability, processing integrity, confidentiality, and privacy.
* **ISO 27001:2013 Certification:** For information security management systems.
* **ISO 9001:2015 Certification:** For quality management systems.
## **Dedicated Support**
Our Enterprise plan offers a dedicated support structure to ensure your success:
* **24/7 Emergency Support:** Priority support for critical service disruptions.
* **Proactive Health and Release Monitoring:** We actively monitor your Xano instances to ensure optimal performance and smooth updates.
* **Database Migration Assistance:** Expert guidance and support for migrating your existing data to Xano.
* **Technical Consultation Services:** Access to our technical experts for architectural guidance and best practices.
This overview provides a glimpse into the advanced capabilities offered by Xano for Enterprise. If your organization requires the flexibility, scalability, security, and support outlined above, we encourage you to reach out to our team to discuss your specific needs and explore how Xano can empower your next generation of applications.
# File Storage In Xano
Source: https://docs.xano.com/file-storage/file-storage-in-xano
## How does file storage work?
In Xano, you are provided a separate "bucket" that can hold all of your files, whether these are files you are providing to your users, or files they are uploading to your application.
You can upload almost anything, from images, to documents and PDFs, and even audio / video.
File storage has two essential components:
* The files themselves
* Database records with metadata
While the files themselves are not stored in your database, if you choose to reference a file in a database record, it will be storing the **metadata**, or general information about the file, such as the filename, size, file type, and a URL to access the file.
**Review all of the available functions for working with files **[**here**](/the-function-stack/functions/file-storage)**.**
## Public vs Private Storage
It's important to note that files uploaded to Xano have static URLs — this means that once a user has a URL to a file stored in your Xano backend, that URL will always be accessible without any kind of authentication or other checks to determine if it should be accessed.
If you have files that you need to restrict access to, you should be utilizing [private file storage](/file-storage/private-file-storage) instead.
You can review all of your public and private files from the **Host Files** tab in the sidebar.
## File Management
The File section enables you to view and manage all of the files (images, videos, audio files, and attachments) in your workspace. You can easily see and search the files of your workspace and see the file name, mime type, size, and date it was created.
If a file appears in this section, then it is included in the overall media storage of your plan. Files will be added here once one of the following happens:
1. Uploading a file directly to the database.
2. Uploading a file directly to the File page.
3. Creating Metadata for any type of file in the function stack.
Files do not need to be added to your database to be a file of your workspace. Creating the metadata of a file through the function stack associates that file with your workspace - even if you do not add it to a record in one of your database tables.
# Private File Storage
Source: https://docs.xano.com/file-storage/private-file-storage
Private file storage is included with our **Pro plan**.
All files stored as private files are only accessible through on-demand time sensitive URL generation. This means that all files in your Private Storage are inaccessible until you generate a new URL in your function stack.
To work with private file storage, there are two key components to understand: **private file database fields** and the **Private File: Sign URL function.**
#### Private File Database Field
To store files in your private files library and have them accessible from your function stacks, you'll need to use a database field that is enabled for private file storage. You can enable this for any of the current file field types. Keep in mind that the file access is defined per field, which means that you can not store both public and private files in the same field.
When private files are enabled for a file storage field, a lock icon is displayed in the field name. You will also notice that private files do not display previews from the database view; this is by design, as the files are not accessible until a new URL is generated.
#### Private File: Sign URL function
To generate a signed URL that enables a private file to be accessible, you first need to retrieve the path of the file, which is stored in the database record. In this example, we have queried our files table and this is the expected return for a private image. The main difference here is that on public files, a URL is returned. For private files, no URL is provided.
We can then leverage the **Private File: Sign URL** function to generate a publicly accessible link to the file. Provide the path as offered from the database record, a TTL (how long in seconds the link should be valid for), and finally a return variable to contain the output of the function
When we run this function, we are returned our new signed URL.
# Xano — Features & Capabilities FAQ
Source: https://docs.xano.com/frequently-asked-questions
An overview of Xano's features, architecture, AI capabilities, security, and enterprise readiness.
Table of Contents
Platform Basics
* [What is Xano, and where does it fit in a company's technology stack?](#what-is-xano,-and-where-does-it-fit-in-a-company's-technology-stack)
* [What types of teams typically use Xano?](#what-types-of-teams-typically-use-xano)
* [What database technology does Xano use?](#what-database-technology-does-xano-use)
* [How should I structure and model my data in Xano?](#how-should-i-structure-and-model-my-data-in-xano)
APIs & Backend Logic
* [How are APIs built and managed in Xano?](#how-are-apis-built-and-managed-in-xano)
* [Can Xano support complex business logic?](#can-xano-support-complex-business-logic)
* [Can Xano be used with code as well as visual workflows?](#can-xano-be-used-with-code-as-well-as-visual-workflows)
* [Does Xano support real-time functionality?](#does-xano-support-real-time-functionality)
Authentication & Access Control
* [How does authentication and authorization work?](#how-does-authentication-and-authorization-work)
* [Does Xano support role-based access control (RBAC)?](#does-xano-support-role-based-access-control-rbac-)
AI-Assisted Development
* [How can teams generate a backend using AI?](#how-can-teams-generate-a-backend-using-ai)
* [How does Xano help manage and evolve database schemas with AI?](#how-does-xano-help-manage-and-evolve-database-schemas-with-ai)
* [Can Xano help generate advanced database queries?](#can-xano-help-generate-advanced-database-queries)
* [Can Xano be used for AI-powered or agent-based workflows?](#can-xano-be-used-for-ai-powered-or-agent-based-workflows)
Extensibility & Integrations
* [How does Xano support custom backend code and external libraries?](#how-does-xano-support-custom-backend-code-and-external-libraries)
* [Can Xano handle background jobs and asynchronous processing?](#can-xano-handle-background-jobs-and-asynchronous-processing)
* [How does Xano integrate with existing systems?](#how-does-xano-integrate-with-existing-systems)
Scaling, Security & Enterprise
* [How does Xano scale as usage grows?](#how-does-xano-scale-as-usage-grows)
* [What are best practices for performance and scaling?](#what-are-best-practices-for-performance-and-scaling)
* [Does Xano offer data and resource isolation?](#does-xano-offer-data-and-resource-isolation)
* [Can I build a multi-tenant or B2B application with Xano?](#can-i-build-a-multi-tenant-or-b2b-application-with-xano)
* [Is Xano suitable for production and enterprise use?](#is-xano-suitable-for-production-and-enterprise-use)
* [How does Xano address security requirements?](#how-does-xano-address-security-requirements)
* [How does Xano handle backups and data recovery?](#how-does-xano-handle-backups-and-data-recovery)
* [Where is my data hosted?](#where-is-my-data-hosted)
* [How can I check Xano's uptime or service status?](#how-can-i-check-xano's-uptime-or-service-status)
* [How does Xano handle AI data and privacy?](#how-does-xano-handle-ai-data-and-privacy)
Development Workflow & Portability
* [How does Xano support development and deployment workflows?](#how-does-xano-support-development-and-deployment-workflows)
* [Can we export APIs and data from Xano?](#can-we-export-apis-and-data-from-xano)
* [How do companies typically adopt Xano?](#how-do-companies-typically-adopt-xano)
* [How does Xano compare to other platforms?](#how-does-xano-compare-to-other-platforms)
Ownership, Billing & Support
* [Who owns my data and what I build on Xano?](#who-owns-my-data-and-what-i-build-on-xano)
* [What happens if I want to leave Xano?](#what-happens-if-i-want-to-leave-xano)
* [What are Xano's usage limits, and what happens if I reach them?](#what-are-xano's-usage-limits,-and-what-happens-if-i-reach-them)
* [How does pricing work, and how can I estimate costs before launching?](#how-does-pricing-work,-and-how-can-i-estimate-costs-before-launching)
* [Can I pause my Xano subscription?](#can-i-pause-my-xano-subscription)
* [What happens if I cancel my subscription?](#what-happens-if-i-cancel-my-subscription)
* [What is Xano's refund policy?](#what-is-xano's-refund-policy)
* [Can I downgrade back to a free plan?](#can-i-downgrade-back-to-a-free-plan)
* [What kind of support do I get with Xano?](#what-kind-of-support-do-i-get-with-xano)
* [How do I get help?](#how-do-i-get-help)
***
### **What is Xano, and where does it fit in a company's technology stack?**
Xano is a backend-as-a-service platform that companies use to build, run, and scale APIs, data models, and backend logic without managing servers or infrastructure. It provides a managed database, API layer, business logic, authentication, and background processing in a single system.
Xano also acts as an execution and data layer for AI agents and agent frontends via standards like MCP (Model Context Protocol), allowing tools like ChatGPT, Claude, or custom agent UIs to securely call APIs, access structured data, and trigger backend workflows. This lets organizations expose real business capabilities to AI without giving agents direct access to production systems.
### **What types of teams typically use Xano?**
Xano is used by application development teams, platform teams, and IT organizations building internal tools, customer-facing applications, or integration layers. It supports collaboration across developers, architects, and less technical contributors.
This makes it suitable for small teams through large organizations.
### **What database technology does Xano use?**
Xano is built on PostgreSQL, a widely adopted, enterprise-grade relational database, which powers Xano's native managed database. Teams can model complex schemas, enforce relationships, and maintain data integrity without operating the database themselves.
You can also [migrate your data to Xano](the-database/migrating-your-data) or connect to existing external databases, allowing organizations to keep their data where it already lives while using Xano as an API, logic, and orchestration layer on top.
**For more info:** [the-database/database](the-database/database)
### **How should I structure and model my data in Xano?**
Xano uses a [relational database](https://www.xano.com/database/) based on Postgres, allowing you to structure data using tables and relationships similar to traditional SQL-based systems. This makes it well-suited for common application patterns such as one-to-many and many-to-many relationships, while still being accessible through a visual interface.
### **How are APIs built and managed in Xano?**
Xano provides a visual API builder that allows teams to create REST APIs using configurable logic blocks, database queries, and integrations. For teams that prefer a code-first workflow, Xano also supports building and editing APIs in code using XanoScript through its IDE extension, giving developers full control when they need it.
Beyond the primary API layer, teams can extend and automate Xano itself using the Xano MCP (Model Context Protocol) server and the Metadata API, which enable programmatic management of resources, environments, and configurations. All APIs are automatically documented and can be exported using OpenAPI (Swagger), making them easy to integrate, test, and govern across teams.
**For more info:** [api](api)
### **Can Xano support complex business logic?**
Yes. Xano's Function Stack is built so that teams can implement validations, workflows, conditional logic, and data transformations directly in the backend, with no limitations based on complexity. Logic is centralized and reusable across multiple applications and clients. This reduces duplication and helps enforce consistent rules across systems.
**For more info:** [building/build-visually/function-stack](building/build-visually/function-stack)
### **Can Xano be used with code as well as visual workflows?**
Yes. Xano supports building backend logic either visually or entirely in code using XanoScript, allowing engineering teams to choose the workflow that best fits their standards and development practices. Visual and code-based logic can coexist in the same backend, giving teams flexibility without fragmenting their architecture.
For cases where teams need to run custom JavaScript or leverage existing Node.js libraries, Xano also supports Lambda functions that execute natively within the Xano environment. This allows organizations to extend their backend with custom code while keeping everything governed, secure, and integrated.
**For more info:** [the-function-stack/building-with-visual-development/custom-functions#custom-functions](the-function-stack/building-with-visual-development/custom-functions#custom-functions)
### **Does Xano support real-time functionality?**
Xano supports real-time use cases through features such as webhooks and WebSockets. For many applications, real-time-like experiences can also be achieved through efficient APIs and frontend polling strategies, depending on the requirements of your app.
### **How does authentication and authorization work?**
Xano includes built-in authentication features such as login, token management, and secure API access. Authorization rules can be customized based on roles, ownership, or custom business logic, giving teams fine-grained control over who can access what.
In addition to native auth, Xano can integrate with common OAuth providers (such as Google, GitHub, and others) as well as custom OAuth services, allowing organizations to plug Xano into existing identity and SSO systems.
This allows organizations to implement secure access controls aligned with internal policies.
**For more info:** [security/best-practices#authentication](security/best-practices#authentication)
### **How can teams generate a backend using AI?**
Xano includes an AI-powered Getting Started Assistant that can generate a database schema, user authentication, and API endpoints from a simple description of your application. This allows teams to go from idea to a working backend in minutes.
Teams can then refine, extend, and govern what the AI produces before deploying it.
**For more info**: [building/build-with-ai/getting-started-assistant](building/build-with-ai/getting-started-assistant)
### **How does Xano help manage and evolve database schemas with AI?**
Xano's Database Assistant lets teams describe schema changes in natural language and apply them safely to their database. It suggests updates to tables, fields, and relationships and allows teams to review every change before committing.
This makes it easier to evolve data models as applications grow without breaking production systems.
**For more info:** [building/build-with-ai/database-assistant](building/build-with-ai/database-assistant)
### **Can Xano help generate advanced database queries?**
Yes. Xano includes a SQL Assistant that can translate natural-language requests into SQL queries. Teams can use it to build complex joins, filters, and aggregations and immediately preview the results.
This reduces the need for manual SQL writing while maintaining full transparency and control.
**For more info:** [building/build-with-ai/sql-assistant](building/build-with-ai/sql-assistant)
### **How does Xano support custom backend code and external libraries?**
Xano supports Lambda functions that allow teams to run custom JavaScript and leverage existing NPM libraries directly inside their backend. This is commonly used for tasks such as document generation, image processing, data transformations, or specialized integrations.
In addition, on certain plans, Xano can connect to external Docker-based microservices, enabling teams to run custom workloads in their own containers while still orchestrating them from Xano's APIs and workflows. Xano's Lambda Assistant further helps teams write and iterate on functions using AI while keeping everything integrated into the broader backend.
**For more info:** [building/build-with-ai/lambda-assistant](building/build-with-ai/lambda-assistant)
### **How does Xano handle AI data and privacy?**
Xano does not store or train on your application data when processing AI requests. Data is used only to generate the requested AI output and is not retained or repurposed.
Third-party AI providers may collect limited usage metadata for billing and performance, but your application data remains yours.
**For more info:** [https://legal.xano.com/privacy-notice](https://legal.xano.com/privacy-notice)
### **Does Xano support role-based access control (RBAC)?**
Yes. Xano supports role-based access control at both the application level and the platform level. For end users of your application, you can define roles, ownership rules, and permission logic that determine which users can access or modify specific data or APIs.
For your internal teams, Xano also provides role-based access to the Xano workspace itself, allowing you to control which developers, operators, or partners can view, edit, or deploy backend logic. This makes it suitable for both secure applications and governed development teams.
**For more info:** [team-collaboration/role-based-access-control-rbac#role-based-access-control-rbac](team-collaboration/role-based-access-control-rbac#role-based-access-control-rbac)
### **Can Xano handle background jobs and asynchronous processing?**
Yes. Xano supports background tasks for long-running or asynchronous operations such as batch processing, integrations, or notifications.
This helps maintain API performance while handling operational workloads reliably.
**For more info:** [the-function-stack/building-with-visual-development/background-tasks#background-tasks](the-function-stack/building-with-visual-development/background-tasks#background-tasks)
### **How does Xano integrate with existing systems?**
Xano can call external APIs, consume webhooks, and act as an integration layer between systems. Teams use it to connect frontends, third-party services, internal tools, and automation platforms through a single, governed backend.
To speed this up, Xano also provides pre-built integration actions and templates for common services (such as auth providers, email, payments, and automation tools), allowing teams to connect systems without writing everything from scratch. This makes Xano well suited for organizations with heterogeneous technology stacks.
**For more info:** [https://www.xano.com/connect/](https://www.xano.com/connect/)
### **Can Xano be used for AI-powered or agent-based workflows?**
Yes. Xano can serve as a backend for AI-driven applications by managing data, orchestrating workflows, and exposing APIs to AI agents. It also supports observability via OpenTelemetry.
This enables teams to add AI capabilities while maintaining backend control and visibility.
**For more info:** [http://docs.xano.com/ai-tools/ai-agents](http://docs.xano.com/ai-tools/ai-agents)
### **How does Xano scale as usage grows?**
Xano can scale infrastructure as demand increases, without requiring teams to manage servers or databases. For organizations with advanced needs, Xano also supports isolated environments.
### **What are best practices for performance and scaling?**
Xano is built to scale automatically as your application grows. Performance best practices include designing efficient queries, using pagination where appropriate, and structuring data to match access patterns. Xano provides tools to help monitor and optimize performance as usage increases.
### **Does Xano offer data and resource isolation?**
Yes. On certain plans, Xano allows you to create separate tenants for the isolation of data and resources, including regional isolation. Whether you're looking to implement CI/CD workflows, offer single-tenancy to customers, customize tenant resources, control releases, or meet data residency requirements, you can easily do it with Xano.This is ideal for SaaS companies with multiple customers who need isolated environments.
**For more info:** [enterprise/enterprise-features/tenant-center#tenant-center](enterprise/enterprise-features/tenant-center#tenant-center)
### **Can I build a multi-tenant or B2B application with Xano?**
Yes. Xano supports multi-tenant architecture through the [Tenant Center](https://www.xano.com/blog/xano-tenant-center/), which is designed for applications that need clear isolation between customers or environments. With Tenant Center, you define a single backend blueprint (your APIs, database schema, and business logic) and then deploy it across multiple tenants while keeping each tenant's data and resources fully isolated. Tenants can run in different geographic regions to meet data-residency or performance requirements, and you can manage releases and versioning across tenants from one control plane. This makes it suitable for SaaS products, enterprise platforms, or any B2B application where separate customer boundaries and operational control matter.
### **Is Xano suitable for production and enterprise use?**
Yes. Xano is designed to run production workloads and is used by organizations supporting real users and business-critical applications. It includes features for security, performance, monitoring, and operational stability.
To read up on how customers are using Xano, check out our [customer case studies page](https://www.xano.com/case-studies/) and some of our real-life customer testimonials below.
"We were able to accelerate the development process without compromising on the essential elements of security and scalability." (Arthur Anouil, [Decathlon](https://www.xano.com/case-study/how-xano-helped-decathlon-get-to-market-and-develop-3x-faster/))
""Xano made it incredibly easy to go from idea → AI-generated backend → production-grade system in a very short time." (Manikant Kella, [Dev.to](https://dev.to/manikant92/promptshield-ai-an-ai-cost-risk-firewall-built-with-xano-346e))
""Xano was my first choice due to its robust logic capabilities combined with a scalable database architecture. This combination would not only facilitate a successful launch but also ensure seamless scaling without additional technical overhead." (Tom Wesołowski for [Playmore](https://www.xano.com/case-study/how-xano-helped-playmore-replace-their-legacy-system-within-three-months/))
### **How does Xano address security requirements?**
Xano provides encryption in transit and at rest, access controls, and secure authentication mechanisms. Security configurations can be tailored to meet organizational requirements. This helps teams meet internal security standards without managing infrastructure directly.
Compliance and security details are maintained in Xano's Trust Center.
**For more info:** [https://security.xano.com/](https://security.xano.com/)
### **How does Xano handle backups and data recovery?**
Xano automatically performs backups of your data to protect against data loss. These backups are managed by Xano and are designed to support recovery in the event of an incident. This allows you to focus on building your application without needing to manage your own backup infrastructure.
### **Where is my data hosted?**
Xano runs on managed [cloud infrastructure](https://www.xano.com/server/) and stores your data in secure data centers. The specific hosting region depends on your instance configuration. Xano is designed to meet common data security and residency requirements for modern applications.
### **How can I check Xano's uptime or service status?**
Xano provides a public status page where you can view current system status and historical incidents. This allows you to quickly verify whether an issue is related to Xano's infrastructure.
### **Can we export APIs and data from Xano?**
Xano provides ways to access and extract your database content, which gives you a practical path to migrate information into a different backend, data warehouse, or cloud environment. Xano also exposes your API definitions via OpenAPI (Swagger) as documentation of how your endpoints behave, which can help other tools or engineers understand how your system works if you rebuild or reimplement parts of it elsewhere. In addition, teams that have written backend logic in XanoScript may be able to reuse parts of that logic conceptually (or translate it to another language).
**For more info:** the-database/database-basics/export-and-sharing
### **How does Xano support development and deployment workflows?**
Xano supports environment management and safe iteration on backend logic, allowing teams to test changes before rolling them out. This enables structured workflows without complex DevOps tooling.
**For more info:** [ci-cd#ci-cd](ci-cd#ci-cd)
### **How do companies typically adopt Xano?**
Companies often start by using Xano for a specific application, workflow, or integration layer, then expand usage as teams see value. Xano can coexist with existing infrastructure. This makes it a low-risk way to modernize backend development incrementally.
### **How does Xano compare to other platforms?**
Xano provides a unified backend platform that combines database, APIs, business logic, authentication, and integrations in one system. This allows teams to avoid stitching together multiple tools for different backend functions. It is designed for visual and code-based development, giving teams flexibility without sacrificing governance.
**For more info:**
* [https://www.xano.com/versus/supabase](https://www.xano.com/versus/supabase)
* [https://www.xano.com/versus/airtable](https://www.xano.com/versus/airtable)
* [https://www.xano.com/versus/bubble](https://www.xano.com/versus/bubble)
### **Who owns my data and what I build on Xano?**
You do. You retain full ownership of everything you build on Xano, including your database schemas, APIs, business logic, and any data processed through your backend. Xano does not claim rights to your intellectual property, applications, or customer data.
Xano's role is to provide the platform and infrastructure that runs your backend—not to own or reuse what you create on top of it.
### **What happens if I want to leave Xano?**
If you decide to move off Xano, you can export your data and API definitions so they can be migrated to another system. Xano supports OpenAPI (Swagger) exports for your APIs and provides mechanisms to retrieve your underlying data.
In the unlikely event that Xano were ever unable to continue operating, the company maintains an exit plan designed to help customers recover their data and API specifications in a structured way.
### **What are Xano's usage limits, and what happens if I reach them?**
Xano plans include limits based on resources such as API requests, storage, and compute. These limits are designed to support applications at different stages, from prototypes to production-scale workloads. If you approach or exceed a limit, Xano provides visibility into usage so you can upgrade or adjust your architecture as needed. Visit our [pricing page](https://www.xano.com/pricing/) for more information about specific plan limits.
### **How does pricing work, and how can I estimate costs before launching?**
Xano pricing is based on the resources required to run your backend, such as compute and storage. Different plans are designed to support different stages of growth. Before launching, you can estimate costs based on your expected usage and scale, and upgrade plans as your application grows.
### **Can I pause my Xano subscription?**
Xano subscriptions cannot be paused. If you're having difficulties, please reach out to our support team for assistance.
### **What happens if I cancel my subscription?**
You will continue to retain access to Xano until the end of your subscription period.
### **What is Xano's refund policy?**
Xano does not offer refunds on monthly plans. We may offer a refund on a yearly subscription during the first thirty days depending on the circumstances. Refunds are not processed automatically upon cancellation; you need to reach out to our support team before you cancel to process your request.
### **Can I downgrade back to a free plan?**
Due to technical limitations in our current infrastructure, it is not currently possible to directly downgrade from a paid plan back to a free plan.
### **What kind of support do I get with Xano?**
All Xano users have access to documentation and community resources. Paid plans include direct support, with higher-tier plans offering faster response times and additional support options. This ensures teams can get help appropriate to the criticality of their application.
### **How do I get help?**
* **Check out the [Xano YouTube Channel](https://www.youtube.com/nocodebackend).** Our YouTube channel is always being updated with tutorials, use case examples, feature announcements, and more.
* **Visit the [Xano Community](https://community.xano.com/).** Ask or answer questions and interact directly with other Xano users.
* **Reach out to our support team.** Just click the option in the lower-left corner anywhere in Xano to be connected to our support team, 24 hours a day.
# AI-Assisted Development
Source: https://docs.xano.com/getting-started-ai
Use Claude Code with the Xano Developer MCP and the Xano CLI to build your backend with AI.
The following guide walks you through setting up an AI-powered [XanoScript](xanoscript/introduction) development workflow in **VS Code** using **Claude Code**, the **Xano Developer MCP**, and the **Xano CLI**.
**Prerequisites:** [Node.js](https://nodejs.org/) 18+, [VS Code](https://code.visualstudio.com/), and [Git](https://git-scm.com/downloads) installed.
This guide uses Claude Code, but the Developer MCP works with Cursor, Codex, Windsurf, VS Code Copilot, and other MCP-compatible AI tools. See the [Developer MCP guide](/developer-mcp/get-started) for platform-specific setup.
Install [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview) — the AI assistant you'll use to write and modify XanoScript locally.
```bash theme={null}
npm install -g @anthropic-ai/claude-code
```
Open your terminal and install the [Xano CLI](/xano-cli/get-started) globally using npm:
```bash theme={null}
npm install -g @xano/cli
```
Then authenticate and pull your workspace:
```bash theme={null}
xano auth
xano workspace pull -d ./my-workspace
```
This creates a `my-workspace` folder in your current directory and downloads your workspace into it. You can also pull into the current folder with `xano workspace pull .`
Next, we recommend initializing a Git repository in your workspace folder so you can track and review the details of what changed before each push.
See the [CLI Get Started](/xano-cli/get-started) guide for full details.
Open the pulled workspace folder in VS Code, then install the [XanoScript Language Server](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript-language-server) extension. This provides syntax highlighting, inline validation, and autocomplete for `.xs` files — without it, they appear as plain text with no error feedback.
**Already using the full XanoScript extension?** If you want to keep it for push/pull, that's fine — but delete any `agents.md` or other `.md` artifact files it created in your workspace root, as these can conflict with the Developer MCP and confuse AI assistants. For the best experience, we recommend using the [XanoScript Language Server](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript-language-server) extension alongside the CLI for push/pull.
The [Developer MCP](/developer-mcp/get-started) gives AI tools direct access to XanoScript documentation and real-time code validation, significantly improving AI-generated XanoScript quality.
In the VS Code terminal, add the Developer MCP to your project:
```bash theme={null}
claude mcp add xano -- npx -y @xano/developer-mcp
```
Not using Claude Code? See the [Developer MCP guide](/developer-mcp/get-started) for setup instructions for Cursor, Windsurf, Codex, VS Code Copilot, and other AI tools.
Launch Claude Code in VS Code and ask it to make a change. For example:
> Add a step to the auth/signup endpoint that sends a welcome email after a successful registration.
Claude Code will read your existing XanoScript, plan the change, and write the updated code — with the Developer MCP providing documentation and validation along the way.
Before pushing, review what the AI changed against your local repository. Pay attention to any table schema changes — renamed or removed columns can affect existing data.
The CLI is safe by default: objects deleted locally won't be removed from your Xano workspace unless you explicitly use the `--delete` flag. If any changes would result in data loss — like dropping a column or deleting a table — the push preview will call them out as destructive operations before you confirm. See [Push & Pull](/xano-cli/push-pull#push-preview) for a full breakdown of what each operation means.
Work on a [development branch](/xano-cli/workspaces-and-branches#create-a-branch) to keep your changes separate from the live branch, or use a **secondary workspace** as your development environment to keep your data schema isolated before promoting to production.
Once you've reviewed your changes, head back to your terminal and run the push yourself — we recommend **not** asking the AI agent to push for you, so you stay in control of what gets applied. See [Using the CLI with AI Agents](/xano-cli/get-started#using-the-cli-with-ai-agents) for tips on managing agent permissions and keeping pushes safe.
**On paid plans**, `xano workspace push` is blocked by default and prompts you to first push to a [Sandbox](/xano-cli/sandbox) — an ephemeral tenant environment where you can test changes, inspect the snapshot diff, and promote them to your workspace. Use `xano sandbox push -d ./my-workspace` and `xano sandbox review` before running the workspace push below.
Start with a dry run to preview what the push will do without applying anything:
```bash theme={null}
xano workspace push -d ./my-workspace --dry-run
```
Review the output carefully, especially any destructive operations or schema changes. When you're ready, run the actual push:
```bash theme={null}
xano workspace push -d ./my-workspace
```
The CLI shows the same preview again and prompts for confirmation before applying anything.
Send a POST request to your auth/signup endpoint and review the results.
```bash theme={null}
curl -X POST "https://your-xano-instance.xano.io/api:abcD123/auth/signup" \
-H "Content-Type: application/json" \
-d '{
"name": "John Doe",
"email": "john.doe@example.com",
"password": "super_secure_password"
}'
```
You should receive a welcome email shortly after the request completes.
*This step is optional, but you can quickly see the parity between your code and the visual representation.*
Head into Xano, and navigate to your `auth/signup` API by clicking API in the sidebar, choose the **Authentication** group, and click `auth/signup`.
You should see the *Send Email* step at the end of the logic, right after the *Create Authentication Token* step.
## Using a different AI tool?
The Developer MCP isn't limited to Claude Code — it works with any AI tool that supports the Model Context Protocol. See the [Developer MCP guide](/developer-mcp/get-started) for platform-specific setup instructions.
* **[Cursor](/developer-mcp/get-started#cursor)** — Add the MCP server via Settings > Tools & Integrations.
* **[Windsurf](/developer-mcp/get-started#windsurf)** — Add the MCP server via Settings > Cascade > Manage Plugins.
* **[Codex](/developer-mcp/get-started#codex)** — Add a `.codex/mcp.json` file to your project.
* **[VS Code Copilot](/developer-mcp/get-started#vs-code)** — Add a `.vscode/mcp.json` file to your project.
***
## What's next
Explore the full set of tools and resources the Developer MCP exposes to your AI assistant.
Learn about push, pull, branching, workflow tests, and more with the Xano CLI.
Dive deeper into the logic that powers your APIs, functions, and background tasks.
Build AI agents in Xano that can reason, use tools, and take actions.
# Building with the VS Code Extension
Source: https://docs.xano.com/getting-started-code
A guide to setting up VS Code for Xano development, editing endpoints in XanoScript, and syncing changes.
**Using Claude Code?** You don't need VS Code at all. Install the [Developer MCP](/developer-mcp/get-started) and use the [Xano CLI](/xano-cli/get-started) to pull, edit, and push — no extension required.
This guide walks you through setting up VS Code for Xano development — connecting your workspace, configuring your AI assistant, editing an endpoint, and syncing changes back to Xano.
Install the [XanoScript extension for VS Code](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript). This provides syntax highlighting, real-time validation, code completion, and a built-in connection manager for syncing with your Xano workspace.
**Using Cursor, Windsurf, or another .vsix-compatible IDE?** Download the extension from the [Open VSX Registry](https://open-vsx.org/extension/xano/xanoscript) and follow your IDE's instructions for installing .vsix files.
**Using the Developer MCP?** Install the [XanoScript Language Server](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript-language-server) instead. It provides syntax highlighting and validation without conflicting with the MCP. The full extension above should not be installed alongside the Developer MCP.
The XanoScript extension works with multiple AI coding tools. Choose the setup that matches your workflow.
Make sure you have **GitHub Copilot Pro or higher** enabled in VS Code. For the best results generating XanoScript, use:
* GPT 5 or higher
* Sonnet 4.5, or Opus
No additional installation is needed — you'll generate AI Agent Instructions when you connect to Xano in the next step. These files help Copilot understand your workspace structure and XanoScript conventions.
Install the [Developer MCP](/developer-mcp/get-started) to give your AI coding tools direct access to XanoScript documentation and real-time code validation. This significantly improves the quality of AI-generated XanoScript.
Quick install for Claude Code:
```bash theme={null}
claude mcp add xano -- npx -y @xano/developer-mcp
```
The Developer MCP replaces the need for AI Agent Instructions — it provides XanoScript context to your AI tools directly.
*Make sure you have the folder you want to work in open before continuing.*
**Using the XanoScript Language Server + CLI?** Run `xano auth` to authenticate, then `xano workspace pull -d ./my-workspace` to pull your workspace. See the [CLI Get Started](/xano-cli/get-started) guide for details, and skip ahead to the next step.
Click *Login to Xano* to authenticate with your Xano account and follow the instructions.
Select your instance from the dropdown that appears, and then select your workspace and your live branch.
After selection, click *Pull Changes* to get everything that's currently present in your Xano workspace.
**If you're using GitHub Copilot**, select *Setup AI Agent Instructions* to generate context files for your workspace. These help Copilot understand your workspace structure and XanoScript conventions. It is highly recommended to generate these for the best possible experience.
**Using the Developer MCP?** Skip this step — the MCP provides XanoScript context to your AI tools directly.
Xano repos follow a very simple structure. Each primitive lives in its folder, with logic stored inside `.xs` files.
**Repository Layout**
```bash theme={null}
api/
authentication/
api_group.xs
000_auth_signup_post.xs
000_auth_login_post.xs
000_auth_me_get.xs
table/
000_user.xs
```
You'll see other folders for things like functions, AI Agents, and more -- for this quick start, we're just looking at APIs and tables.
Navigate to `api/authentication/000_auth_signup_post.xs`
Add a new function below `security.create_auth_token`. Order matters — this ensures the email is sent only after signup succeeds. This is our `send_email` function; just copy and paste the code below.
```
util.send_email {
service_provider = "xano"
subject = "Welcome!"
message = "Thanks for checking out Xano. We're so glad you're here."
} as $x1
```
This is what you should be seeing now:
Save your changes, and then click the option in the XanoScript extension to stage your changes.
Push your changes to Xano. Progress is shown in a notification in the bottom-right corner.
Prefer the terminal? You can also use `xano workspace push` and `xano workspace pull` via the [Xano CLI](/xano-cli/get-started) instead of the extension's UI.
**Git works like it always has** — your workspace is plain files on disk. Commit your changes to Git before or after pushing to Xano for full version history, branching, and collaboration.
Send a POST request to your auth/signup endpoint and review the results.
```bash theme={null}
curl -X POST "https://your-xano-instance.xano.io/api:abcD123/auth/signup" \
-H "Content-Type: application/json" \
-d '{
"name": "John Doe",
"email": "john.doe@example.com",
"password": "super_secure_password"
}'
```
You should receive a welcome email shortly after the request completes.
*This step is optional, but you can quickly see the parity between your code and the visual representation.*
Head into Xano, and navigate to your `auth/signup` API by clicking API in the sidebar, choose the **Authentication** group, and click `auth/signup`.
You should see the *Send Email* step at the end of the logic, right after the *Create Authentication Token* step.
# Building Visually
Source: https://docs.xano.com/getting-started-visual
A guide to using Xano's visual builder to inspect, validate, and iterate on your backend workflows.
This guide walks you through running a pre-built signup endpoint, inspecting the steps, and making a small modification to send a welcome email to new users. Xano gives you a `user` table and default `authentication` APIs out of the box, and we'll use those here.
Navigate to API in the sidebar, choose the Authentication group, and select your auth/signup endpoint.
Click Run in the top-right corner.
Enter a name, email, and a password to create a new user. You'll use this later on, so make sure to remember the credentials you enter here. Click Run in the lower-right corner to execute the request.
If all goes well, you should see a successful response with an
authentication token
returned.
The visual builder has two different views: **Canvas** and **Stack**. Canvas presents a node-style view of the steps in your endpoint, while Stack presents a linear, step-by-step list of the same information, more similar to traditional code.
Click on a step to see more details about what it does and how it's configured.
Let's add a step to send a welcome email after signup. We'll use the **Send Email** function for this.
Click the + Add Step button at the bottom of the stack view, or in between the Create Authentication Token step and the Response in the canvas view.
Select the **Send Email** function.
Add a subject and a body for the email. Xano includes free access to Resend for development and testing (up to 100 emails), limited to the email address you signed up for Xano with.
Click Save to save the step.
Run the signup endpoint again with a different email address. You should receive a welcome email shortly after the run completes.
After a run, open the Timing dropdown to view step timing, output, inputs, and variables.
Click the > next to the first Get Record step. We can see the first Get Record function returned `null`, meaning that the user didn't already exist.
Try to register the same user again to see how the output changes.
Expand the `input` and `vars` sections for each step to see how the data changes throughout execution.
Xano will automatically hide information labeled as sensitive, such as password fields, in the run panel.
Click the dropdown in the upper-right corner and choose Publish Now. This immediately deploys your changes to the live API.
Click to copy the endpoint URL.
Take it over to your favorite API testing tool, like [Postman](https://www.postman.com/), [Insomnia](https://www.insomnia.rest), or [Bruno](https://www.usebruno.com). Send a `POST` request to the signup endpoint with the required parameters (name, email, password) in the body.
You should see a successful response, just like in Xano, and have received another welcome email.
## Troubleshooting
Click API in the sidebar.
Click the + Create API button in the top-right corner.
Select Authentication
Add the three default API endpoints offered: `/signup`, `/login`, and `/me`
**Error Traceback (Most recent call last):**
at `API /auth/signup(Get Record)`
Exception: Param: field\_value - Missing param: field\_value
> The required parameters were not provided when running the endpoint -- specifically the email. Make sure to enter a name, email, and a password.
**Error Traceback (Most recent call last):**
at `API /auth/signup(Precondition)`
Exception: Access Denied
> The account already exists. Try using a different email address to create a new user.
**Error Traceback (Most recent call last):**
at `API /auth/signup(Add Record)`
Exception: Param: password - Input does not meet minimum length requirement of 8 characters
> Password inputs have some default requirements: at least 8 characters, one uppercase letter, and one number. Make sure your password meets these requirements.
# Understanding enforce_hidden_fields for Add, Edit, and Add/Edit Record
Source: https://docs.xano.com/hidden-fields-fix
# The Issue
If you have an input or variable in your logic that shares the name of a database column you're targeting with Add Record, Edit Record, or Add/Edit Record, that column's data can be overwritten, even if it's hidden in the function.
* This behavior is triggered any time XanoScript is saved, either via the UI editor, Agent Mode, or pushing changes via the CLI and Metadata API.
* The XanoScript code shows no change before and after, and the issue is invisible in both version history and Run & Debug.
# Previous Workarounds
* Show/hide the field in the visual UI, and re-save, which fixes it temporarily until the XanoScript is saved again.
* Renaming the inputs or variables to not match a column name
* Using the Patch Record function instead
# Who's impacted?
You may be affected if an existing function was originally built visually, later edited in XanoScript or with AI, and includes an input or variable whose name matches a column used by an Add, Edit, or Add/Edit Record statement.
Functions created entirely in XanoScript are generally not affected.
# What's the fix?
For functions impacted by this that you aren't already addressing in other ways, you can use the new **Enforce Hidden Fields** option. This can be enabled by either checking the box in the function panel, or by adding `enforce_hidden_fields = true` to the function's XanoScript, and saving your changes.
```java theme={null}
db.add user {
enforce_hidden_fields = false
data = {...
```
This fix is designed to preserve compatibility, meaning that existing statements retain the old behavior until changed, and new statements default to the new `enforce_hidden_fields` behavior.
Please note that after applying **enforce\_hidden\_fields**, when you save your changes, this line of code will **disappear**. Do not be alarmed; this is expected behavior and the new behavior is still applied.
# Example Behaviors
## Impacted functions
Using these example inputs:
Running an Add Record statement on a table with `name` and `email` fields, and hiding the `email` field in the function, with the goal of that value not being written, `email` will be overwritten with whatever value is supplied in the `email` input.
## Impacted functions after enabling `enforce_hidden_fields`
Using these example inputs:
Running an Add Record statement on a table with `name` and `email` fields, and hiding the `email` field in the function, with the goal of that value not being written, `email` will be written with the default value specified in the table, with no value, or with a null value if the field is nullable.
# Get Started
Source: https://docs.xano.com/index
Go from zero to a live backend in minutes.
Xano is a secure, scalable backend-as-a-service platform that gives you everything you need to build and operate your backend — without managing infrastructure. Build fast with AI, then validate and refine visually with full transparency into your core business logic.
* Build your backend with AI using [Xano Agent](/building/xano-agent), code-first tools like Claude Code and Cursor, or the built-in AI assistants
* Power your entire backend — APIs, workflows, database, runtime, CI/CD, and observability
* Maintain complete visibility into your business logic with visual validation, audit trails, and standardized architecture
* Deploy and scale on enterprise-grade infrastructure with HIPAA compliance, SOC 2 certification, GDPR readiness — without managing DevOps
***
## Build your first backend
Xano gives you multiple ways to build — pick whichever fits how you like to work. Everything you create in one mode is fully visible and editable in the others, so you can switch freely at any time.
Xano Agent is an AI assistant built into Xano that can build your entire backend from a prompt. Describe what you need — tables, APIs, auth, business logic — and Xano Agent writes the XanoScript, presents a plan, and lets you review every change before publishing.
Open Xano Agent from inside your workspace by clicking Xano Agent. You'll see a chat interface where you can describe what you want to build.
Tell Xano Agent what you need. Be as specific as you like — it handles everything from simple CRUD to complex multi-table schemas with auth, relationships, and business logic.
For example:
> Build a backend for a simple Instagram clone that supports both image and video uploads, threaded comments, likes, follows, private accounts, "close friends" lists for private / limited posts, and direct messaging.
Xano Agent creates database tables, API endpoints, middleware, and any other resources your backend needs. You can inspect the generated XanoScript in a diff-style view, and select between Canvas, Stack, and XanoScript views.
Click **Push to Draft** to push everything the agent has built to your workspace in a draft state. The changes will be ready for your review before publishing to production.
Your backend is now live. Open it in the Xano dashboard to see everything the agent built — fully visible and editable in the visual builder.
Some items, such as API groups and database tables, do not have available draft states, so they need to be published before continuing. The Agent will walk you through this.
After pushing to draft and testing, you're ready to publish. Click the **Publish** button, and you'll be presented with a diff-style view of all changes ready to be published.
When you're ready, click **Publish** at the bottom of the screen to push these changes to live.
See the full guide — tips for effective prompts, what Xano Agent can build, and how it compares to other AI tools in Xano.
This guide walks you through setting up a local XanoScript development workflow using the **Xano CLI** and **Claude Code**. The CLI syncs your workspace to Xano; Claude Code writes the XanoScript.
**Prerequisites:** [Node.js](https://nodejs.org/) 18+, [VS Code](https://code.visualstudio.com/), and [Git](https://git-scm.com/downloads) installed.
1
### Install Claude Code
Install [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview) — the AI assistant you'll use to write and modify XanoScript locally.
```bash theme={null}
npm install -g @anthropic-ai/claude-code
```
2
### Install the Xano CLI
Install the [Xano CLI](/xano-cli/get-started) globally using npm:
```bash theme={null}
npm install -g @xano/cli
```
3
### Authenticate
Connect the CLI to your Xano account. This opens your browser to log in, then guides you through selecting your instance, workspace, and branch.
```bash theme={null}
xano auth
```
If you don't have a Xano account yet, you can create one for free during this step.
4
### Pull your workspace
Download your workspace as local XanoScript files — this is where Claude Code will read and write changes.
```bash theme={null}
xano workspace pull -d ./my-workspace
```
**Starting fresh?** Create a new workspace first with `xano workspace create "My App"`, then pull it.
We recommend initializing a Git repository in your workspace folder so you can track and review exactly what changed before each push.
5
### Open in VS Code
Open the workspace folder in VS Code, then install the [XanoScript Language Server](https://marketplace.visualstudio.com/items?itemName=xano.xanoscript-language-server) extension. This provides syntax highlighting, inline validation, and autocomplete for `.xs` files — without it, they appear as plain text with no error feedback.
**Already using the full XanoScript extension?** If you want to keep it for push/pull, that's fine — but delete any `agents.md` or other `.md` artifact files it created in your workspace root, as these can conflict with the Developer MCP and confuse AI assistants.
6
### Connect the Developer MCP
In the VS Code terminal, add the [Developer MCP](/developer-mcp/get-started) to your project. This gives Claude Code direct access to XanoScript documentation and real-time code validation — significantly improving the quality of AI-generated XanoScript.
```bash theme={null}
claude mcp add xano -- npx -y @xano/developer-mcp
```
**Install Xano Skills too.** Alongside the MCP, Xano ships two agent skills — `xano-init` for guided workspace setup and `xanoscript-docs-expert` for deep XanoScript reference. Install both into Claude Code globally:
```bash theme={null}
npx skills add xano-inc/xano-developer-mcp -a claude-code -g
```
Skills work with Codex, Cursor, Windsurf, and other agents too. See [Xano Skills](/developer-mcp/get-started#xano-skills) for more options.
7
### Build, review, and push
Launch Claude Code and describe what you want to build:
```bash theme={null}
claude
```
For example:
> Create a notes table with title, content, and is\_archived fields. Then create CRUD API endpoints for notes.
Claude Code will write the XanoScript files directly into your local workspace. When it's done, review what changed in your Git repository before pushing.
We recommend pushing yourself from the terminal rather than asking the AI agent to do it — see [Using the CLI with AI Agents](/xano-cli/get-started#using-the-cli-with-ai-agents) for guidance on keeping control of what gets applied.
On paid plans, `xano workspace push` is blocked by default — you'll push to a [sandbox](/testing-debugging/sandbox) instead. The sandbox spins up an isolated ephemeral environment where you can inspect, test, and review a full diff before anything touches your workspace:
```bash theme={null}
xano sandbox push -d ./my-workspace # push changes to an isolated sandbox
xano sandbox preview # open the sandbox to review and test
```
From the sandbox preview, click **Review & Push** to see a diff of all changes, choose your target branch, and deploy when ready.
**On a free plan?** You can push directly with `xano workspace push -d ./my-workspace`. Use `--dry-run` to preview the impact without applying anything.
Work on a [development branch](/xano-cli/workspaces-and-branches#create-a-branch) to keep your changes separate from the live branch, or use a **secondary workspace** as your development environment to keep your data schema isolated before promoting to production.
## Git works like it always has
Your workspace is plain files on disk. `git init`, commit, branch, open PRs — everything you already do. Xano's CLI push/pull fits right into your existing Git workflow, not the other way around.
Not using Claude Code? The Developer MCP works with any AI tool that supports the Model Context Protocol — including Cursor, Windsurf, Codex, and VS Code Copilot. See the [Developer MCP guide](/developer-mcp/get-started) for setup instructions.
This guide walks you through running a pre-built signup endpoint, inspecting the steps, and making a small modification to send a welcome email to new users. Xano gives you a `user` table and default `authentication` APIs out of the box, and we'll use those here.
Navigate to API in the sidebar, choose the Authentication group, and select your auth/signup endpoint.
Click Run in the top-right corner.
Enter a name, email, and a password to create a new user. You'll use this later on, so make sure to remember the credentials you enter here. Click Run in the lower-right corner to execute the request.
If all goes well, you should see a successful response with an
authentication token
returned.
The visual builder has two different views: **Canvas** and **Stack**. Canvas presents a node-style view of the steps in your endpoint, while Stack presents a linear, step-by-step list of the same information, more similar to traditional code.
Click on a step to see more details about what it does and how it's configured.
Let's add a step to send a welcome email after signup. We'll use the **Send Email** function for this.
Click the + Add Step button at the bottom of the stack view, or in between the Create Authentication Token step and the Response in the canvas view.
Select the **Send Email** function.
Add a subject and a body for the email. Xano includes free access to Resend for development and testing (up to 100 emails), limited to the email address you signed up for Xano with.
Click Save to save the step.
Run the signup endpoint again with a different email address. You should receive a welcome email shortly after the run completes.
After a run, open the Timing dropdown to view step timing, output, inputs, and variables.
Click the > next to the first Get Record step. We can see the first Get Record function returned `null`, meaning that the user didn't already exist.
Try to register the same user again to see how the output changes.
Expand the `input` and `vars` sections for each step to see how the data changes throughout execution.
Xano will automatically hide information labeled as sensitive, such as password fields, in the run panel.
Click the dropdown in the upper-right corner and choose Publish Now. This immediately deploys your changes to the live API.
Click to copy the endpoint URL.
Take it over to your favorite API testing tool, like [Postman](https://www.postman.com/), [Insomnia](https://www.insomnia.rest), or [Bruno](https://www.usebruno.com). Send a `POST` request to the signup endpoint with the required parameters (name, email, password) in the body.
You should see a successful response, just like in Xano, and have received another welcome email.
### Troubleshooting
Click API in the sidebar.
Click the + Create API button in the top-right corner.
Select Authentication
Add the three default API endpoints offered: `/signup`, `/login`, and `/me`
**Error Traceback (Most recent call last):**
at `API /auth/signup(Get Record)`
Exception: Param: field\_value - Missing param: field\_value
> The required parameters were not provided when running the endpoint -- specifically the email. Make sure to enter a name, email, and a password.
**Error Traceback (Most recent call last):**
at `API /auth/signup(Precondition)`
Exception: Access Denied
> The account already exists. Try using a different email address to create a new user.
**Error Traceback (Most recent call last):**
at `API /auth/signup(Add Record)`
Exception: Param: password - Input does not meet minimum length requirement of 8 characters
> Password inputs have some default requirements: at least 8 characters, one uppercase letter, and one number. Make sure your password meets these requirements.
***
## Keep going
Build your entire backend from a prompt with the built-in AI assistant.
Learn more about all of the logic that can power your backend.
Design, manage, and query your database.
Build AI agents that can reason, use tools, and take actions.
Add user auth, RBAC, and OAuth/SSO to your API.
# API Rate Limit
Source: https://docs.xano.com/instances/api-rate-limit
To keep Xano's free plan safe and fair for everyone sharing the resources of our free server instance, a rate limit of **10 requests every 20 seconds** is enforced.
When you encounter the rate limit, you'll see a message like this:
```json theme={null}
{"code":"ERROR_CODE_TOO_MANY_REQUESTS","message":"Whoa there! Your plan only supports 10 requests per 20 seconds. Upgrade options and additional information is available at: https://xano.gitbook.io/xano/instances/api-rate-limit"}
```
### What can I do when I hit the rate limit?
* Wait up to 20 seconds before sending a new request
* Upgrade to a [paid plan](https://www.xano.com/pricing).
Rate limits **do not apply** when testing inside of Xano — you can use our [Run and Debug features](/the-function-stack/building-with-visual-development#testing-a-draft) to test as much as you'd like!
# Partner Integration Guide
Source: https://docs.xano.com/integration/integration-guide
Learn how to integrate with Xano through programmatic backend building or by embedding your product into the Xano ecosystem.
We're thankful that you're considering integrating with Xano, and your user base will be as well. Xano offers a scalable, secure backend platform at the forefront of building visually, with code, with AI, or all three. We provide different ways to integrate, depending on your use case.
You can allow your users to build a backend from your platform or service by using the Metadata API or Xano MCP server.
You can allow your users to utilize your platform or service from within Xano by building a snippet or action that they can import into their Xano workspaces.
***
## Building in Xano from your platform or service
Xano provides a robust set of APIs that enable you to programmatically build a backend. This is done through the **Metadata API**, which gives you access to every aspect of the Xano system — from creating and managing database tables to building APIs, Reusable Functions, Tasks, and more. It's a great way to allow your users to, for example, build a backend for their app or website without leaving your platform.
The Metadata API has a significant number of endpoints available to you depending on what actions you want to offer to your users, and all they have to do is provide their own Metadata API access token from their Xano account. All of our users can generate these tokens and they do not require a paid plan to do so.
All of the features available through the Metadata API are also available through the Xano MCP server, which allows you to leverage AI agents and tool calls on your user's behalf.
Check out the full Metadata API docs
Check out the full Xano MCP server docs
## Integrating Your Product into Xano
In Xano, users can build an entire backend from scratch; this includes a database, logic for APIs, AI Agents, and more. If your service has REST or GraphQL API endpoints available, you can easily offer them to Xano users to utilize in their backend builds.
You don't actually need to do anything here -- Xano users can call any external API they want already. The advantage to following this guide is all about visibility and control over the experience, enabling you to expand your reach to the Xano base in new ways, and making it much easier for them to use your service.
We have two different ways to integrate your product into Xano:
* **Actions**
Actions are a way to offer your service as a dependency-free function that Xano users can use in their backend builds. Dependency free just means that there are no database tables or other more complex additions; it's just the logic that's necessary.
Actions can be built into Action Packages, allowing you to offer them as a single entity that can be installed into a Xano workspace while containing multiple separate Actions.
This option is best for simple services that can be represented with nothing other than API calls. Users can try your Actions without even signing into Xano, which can get them to see the value of your platform or service faster.
* **Snippets**
Snippets are similar to Actions, but are more robust in that they can contain multiple APIs, AI Agents, database tables; anything that can be built in Xano can be included in a Snippet.
This option is best if your service shines when it's integrated into a larger backend, or if you have a lot of complex logic that you want to offer to Xano users.
# Terms & Conditions
Source: https://docs.xano.com/legal
### Agreement to Terms
These Terms of Use constitute a legally binding agreement made between you, whether personally or on behalf of an entity (“you”) and Xano, Inc. ("Company", “we”, “us”, or “our”), concerning your access to and use of the [https://www.xano.com](https://www.xano.com/) website as well as any other media form, media channel, mobile website or mobile application related, linked, or otherwise connected thereto (collectively, the “Site”). You agree that by accessing the Site, you have read, understood, and agree to be bound by all of these Terms of Use. IF YOU DO NOT AGREE WITH ALL OF THESE TERMS OF USE, THEN YOU ARE EXPRESSLY PROHIBITED FROM USING THE SITE AND YOU MUST DISCONTINUE USE IMMEDIATELY.
Supplemental terms and conditions or documents that may be posted on the Site from time to time are hereby expressly incorporated herein by reference. We reserve the right, in our sole discretion, to make changes or modifications to these Terms of Use at any time and for any reason. We will alert you about any changes by updating the “Last updated” date of these Terms of Use, and you waive any right to receive specific notice of each such change. It is your responsibility to periodically review these Terms of Use to stay informed of updates. You will be subject to, and will be deemed to have been made aware of and to have accepted, the changes in any revised Terms of Use by your continued use of the Site after the date such revised Terms of Use are posted.
The information provided on the Site is not intended for distribution to or use by any person or entity in any jurisdiction or country where such distribution or use would be contrary to law or regulation or which would subject us to any registration requirement within such jurisdiction or country. Accordingly, those persons who choose to access the Site from other locations do so on their own initiative and are solely responsible for compliance with local laws, if and to the extent local laws are applicable.
The Site is intended for users who are at least 18 years old. Persons under the age of 18 are not permitted to use or register for the Site.
### **Intellectual Property Rights**
Unless otherwise indicated, the Site is our proprietary property and all source code, databases, functionality, software, website designs, audio, video, text, photographs, and graphics on the Site (collectively, the “Content”) and the trademarks, service marks, and logos contained therein (the “Marks”) are owned or controlled by us or licensed to us, and are protected by copyright and trademark laws and various other intellectual property rights and unfair competition laws of the United States, international copyright laws, and international conventions. The Content and the Marks are provided on the Site “AS IS” for your information and personal use only. Except as expressly provided in these Terms of Use, no part of the Site and no Content or Marks may be copied, reproduced, aggregated, republished, uploaded, posted, publicly displayed, encoded, translated, transmitted, distributed, sold, licensed, or otherwise exploited for any commercial purpose whatsoever, without our express prior written permission.
Provided that you are eligible to use the Site, you are granted a limited license to access and use the Site and to download or print a copy of any portion of the Content to which you have properly gained access solely for your personal, non-commercial use. We reserve all rights not expressly granted to you in and to the Site, the Content and the Marks.
### **User Representations**
By using the Site, you represent and warrant that: (1) all registration information you submit will be true, accurate, current, and complete; (2) you will maintain the accuracy of such information and promptly update such registration information as necessary; (3) you have the legal capacity and you agree to comply with these Terms of Use; (4) you are not a minor in the jurisdiction in which you reside; (5) you will not access the Site through automated or non-human means, whether through a bot, script or otherwise; (6) you will not use the Site for any illegal or unauthorized purpose; and (7) your use of the Site will not violate any applicable law or regulation.
If you provide any information that is untrue, inaccurate, not current, or incomplete, we have the right to suspend or terminate your account and refuse any and all current or future use of the Site (or any portion thereof).
### **User Registration**
You may be required to register with the Site. You agree to keep your password confidential and will be responsible for all use of your account and password. We reserve the right to remove, reclaim, or change a username you select if we determine, in our sole discretion, that such username is inappropriate, obscene, or otherwise objectionable.
### **Fees And Payment**
We accept the following forms of payment:\
\
\- Visa \
\- Mastercard \
\- American Express \
\- Maestro\
\- Discover\
\- JCB\
\- Diners Club\
\- Apple Pay\
\- Google Pay\
\- UnionPay (Credit & Debit)\
\- Carte Bancaire\
\
You may be required to purchase or pay a fee to access some of our services. You agree to provide current, complete, and accurate purchase and account information for all purchases made via the Site. You further agree to promptly update account and payment information, including email address, payment method, and payment card expiration date, so that we can complete your transactions and contact you as needed. We bill you through an online billing account for purchases made via the Site. Sales tax will be added to the price of purchases as deemed required by us. We may change prices at any time. All payments shall be in U.S. dollars.
You agree to pay all charges or fees at the prices then in effect for your purchases, and you authorize us to charge your chosen payment provider for any such amounts upon making your purchase. If your purchase is subject to recurring charges, then you consent to our charging your payment method on a recurring basis without requiring your prior approval for each recurring charge, until you notify us of your cancellation.
We reserve the right to correct any errors or mistakes in pricing, even if we have already requested or received payment. We also reserve the right to refuse any order placed through the Site.
### **Failure of Payment**
Failure to complete payment for your Xano subscription will automatically result in the termination of your Xano instance.
After the first failed attempt to complete payment, you will no longer have access to your Xano Instance and its contents. Attempts to collect payment for your subscription will be executed with the designated payment method on your account. You can find and make changes to this on the billing page.
There will be several attempts to collect payment over a 7 day period. During this period, you will receive email notifications at the email associated with your account of failed payment collection. After this period and no successful payment collection, your instance will be terminated. This will cause loss of data and the contents of the Instance, including any live API endpoints.
It is your responsibility to update your billing information with a valid form of payment. You should [contact support](mailto:support@xano.com) immediately with any questions regarding failed payment on your account.
### **Free Plan**
We offer a FREE plan to new users who register with the Site. The account will not be charged and the subscription will be suspended until upgraded to a paid version at the end of the free plan.
### **Cancellation**
All purchases are non-refundable. You can cancel your subscription at any time by logging into your account. Your cancellation will take effect at the end of the current paid term. \
\
If you are unsatisfied with our services, please email us at [support@xano.com](mailto:support@xano.com).
### Ownership Transfer
Transfer of account ownership may only be done by the [Instance](https://docs.xano.com/what-xano-includes/instance) owner. The Instance owner is defined by the primary email of an instance. Xano will not honor team members, agency partners, or other third parties who request ownership be put in their name or other parties. The Instance owner may transfer ownership to another party by logging into the Instance, changing the primary Email of the account, and following the multi-step procedure.
### **Exit Plan**
If Xano is no longer solvent/operating during the term of any active paid subscription, it will grant a perpetual license to the owner of each active subscription. This license will be free of charge and remove any support and hosting obligations. Additional instructions will be provided as to how to setup Xano in each customer's own cloud environment and migrate their data. Downtime may be required to perform this migration, so it will be important to choose an appropriate time to properly schedule this migration to minimize impact on any customer traffic.
This does not apply to any customers who have custom terms set forth in their enterprise agreements.
### Acquisition Clause
In the event that Xano is acquired by another company during the term of any active paid subscription, we commit to ensuring that the software will not be modified in any way that restricts or limits the functionality of the product as it existed at the time of acquisition. We will maintain the same level of service and feature availability for the duration of the active subscription term. Any planned modifications that could impact the existing functionalities will be communicated to you in advance, and we will provide options to mitigate any potential disruptions.
### Software
We may include software for use in connection with our services. If such software is accompanied by an end user license agreement (“EULA”), the terms of the EULA will govern your use of the software. If such software is not accompanied by a EULA, then we grant to you a non-exclusive, revocable, personal, and non-transferable license to use such software solely in connection with our services and in accordance with these Terms of Use. Any Software and any related documentation is provided “as is” without warranty of any kind, either express or implied, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. You accept any and all risk arising out of use or performance of any Software. You may not reproduce or redistribute any software except in accordance with the EULA or these Terms of Use.
### Acceptable Use Policy
You may not access or use the Site for any purpose other than that for which we make the Site available. The Site may not be used in connection with any commercial endeavors except those that are specifically endorsed or approved by us and outlined in this AUP.
As a user of the Site, you agree to not conduct the follow prohibited activities:
1. Make any unauthorized use of the Site, including collecting usernames and/or email addresses of users by electronic or other means for the purpose of sending unsolicited email, or creating user accounts by automated means or under false pretenses.
2. Circumvent, disable, or otherwise interfere with security-related features of the Site, including features that prevent or restrict the use or copying of any Content or enforce limitations on the use of the Site and/or the Content contained therein.
3. Trick, defraud, or mislead us and other users, especially in any attempt to learn sensitive account information such as user passwords.
4. Make improper use of our support services or submit false reports of abuse or misconduct.
5. Use any information obtained from the Site in order to harass, abuse, or harm another person.
6. Use the Site as part of any effort to compete with us or otherwise use the Site and/or the Content for any revenue-generating endeavor or commercial enterprise.
7. Decipher, decompile, disassemble, or reverse engineer any of the software comprising or in any way making up a part of the Site.
8. Attempt to bypass any measures of the Site designed to prevent or restrict access to the Site, or any portion of the Site.
9. Harass, annoy, intimidate, or threaten any of our employees or agents engaged in providing any portion of the Site to you.
10. Copy or adapt the Site’s software, including but not limited to Flash, PHP, HTML, JavaScript, or other code.
11. Upload or transmit (or attempt to upload or to transmit) viruses, Trojan horses, or other material, including excessive use of capital letters and spamming (continuous posting of repetitive text), that interferes with any party’s uninterrupted use and enjoyment of the Site or modifies, impairs, disrupts, alters, or interferes with the use, features, functions, operation, or maintenance of the Site.
12. Disparage, tarnish, or otherwise harm, in our opinion, us and/or the Site.
13. Use the Site in a manner inconsistent with any applicable laws or regulations.
14. Except as may be the result of standard search engine or Internet browser usage, use, launch, develop, or distribute any automated system, including without limitation, any spider, robot, cheat utility, scraper, or offline reader that accesses the Site, or using or launching any unauthorized script or other software.
15. Engage in unauthorized framing of or linking to the Site.
16. Interfere with, disrupt, or create an undue burden on the Site or the networks or services connected to the Site.
17. Attempt to impersonate another user or person or use the username of another user.
18. Delete the copyright or other proprietary rights notice from any Content.
19. Upload or transmit (or attempt to upload or to transmit) any material that acts as a passive or active information collection or transmission mechanism, including without limitation, clear graphics interchange formats (“gifs”), 1×1 pixels, web bugs, cookies, or other similar devices (sometimes referred to as “spyware” or “passive collection mechanisms” or “pcms”).
20. Upload or share content that infringes on copyrighted, trademarked, or propiretary work without proper authorization.
21. Violate any privacy laws, including the GDPR or equivalent local regulations, when collecting, storing, or processing personal or sensitive information.
### User Generated Contributions
The Site may invite you to chat, contribute to, or participate in blogs, message boards, online forums, and other functionality, and may provide you with the opportunity to create, submit, post, display, transmit, perform, publish, distribute, or broadcast content and materials to us or on the Site, including but not limited to text, writings, video, audio, photographs, graphics, comments, suggestions, or personal information or other material (collectively, “Contributions”). Contributions may be viewable by other users of the Site and through third-party websites. As such, any Contributions you transmit may be treated as non-confidential and non-proprietary. When you create or make available any Contributions, you thereby represent and warrant that:
1. The creation, distribution, transmission, public display, or performance, and the accessing, downloading, or copying of your Contributions do not and will not infringe the proprietary rights, including but not limited to the copyright, patent, trademark, trade secret, or moral rights of any third party.
2. You are the creator and owner of or have the necessary licenses, rights, consents, releases, and permissions to use and to authorize us, the Site, and other users of the Site to use your Contributions in any manner contemplated by the Site and these Terms of Use.
3. You have the written consent, release, and/or permission of each and every identifiable individual person in your Contributions to use the name or likeness of each and every such identifiable individual person to enable inclusion and use of your Contributions in any manner contemplated by the Site and these Terms of Use.
4. Your Contributions are not false, inaccurate, or misleading.
5. Your Contributions are not unsolicited or unauthorized advertising, promotional materials, pyramid schemes, chain letters, spam, mass mailings, or other forms of solicitation.
6. Your Contributions are not obscene, lewd, lascivious, filthy, violent, harassing, libelous, slanderous, or otherwise objectionable (as determined by us).
7. Your Contributions do not ridicule, mock, disparage, intimidate, or abuse anyone.
8. Your Contributions are not used to harass or threaten (in the legal sense of those terms) any other person and to promote violence against a specific person or class of people.
9. Your Contributions do not violate any applicable law, regulation, or rule.
10. Your Contributions do not violate the privacy or publicity rights of any third party.
11. Your Contributions do not contain any material that solicits personal information from anyone under the age of 18 or exploits people under the age of 18 in a sexual or violent manner.
12. Your Contributions do not violate any applicable law concerning child pornography, or otherwise intended to protect the health or well-being of minors.
13. Your Contributions do not include any offensive comments that are connected to race, national origin, gender, sexual preference, or physical handicap.
14. Your Contributions do not otherwise violate, or link to material that violates, any provision of these Terms of Use, or any applicable law or regulation.
Any use of the Site in violation of the foregoing violates these Terms of Use and may result in, among other things, termination or suspension of your rights to use the Site.
### Xano Actions
Xano may make available templates, pre-built configurations, workflows, functions, scripts, connectors, logic, API components, database structures, or other materials for use with the Site or Xano services, including through any related marketplace, directory, community, or discovery page ("Xano Actions"). Xano Actions may be created or published by Xano, users, community members, or other third parties. Except for Xano Actions expressly identified by Xano as official Xano-provided materials, Xano Actions are user-generated or third-party materials and are not reviewed, endorsed, certified, warranted, or guaranteed by Xano for security, privacy, compliance, accuracy, functionality, availability, suitability, or fitness for any particular purpose.
You are solely responsible for evaluating, testing, validating, configuring, securing, and determining whether any Xano Action is appropriate for your intended use before installing, deploying, publishing, or using it, including with any live, real, personal, sensitive, regulated, or confidential data. Your installation or use of any Xano Action is at your own risk. We recommend that you install Xano Actions only from Xano's official website ([https://www.xano.com/actions/discover](https://www.xano.com/actions/discover)) or other Xano-controlled channels, and that you inspect and test any Xano Action in a non-production environment using test data before using it in any application or environment that processes real data. Xano is not responsible or liable for any loss, damage, security incident, data loss, unauthorized access, compliance failure, service interruption, application error, malfunction, vulnerability, or other claim or harm arising out of or relating to any Xano Action that you install, access, modify, deploy, publish, or use.
### Contribution License
By posting your Contributions to any part of the Site or making Contributions accessible to the Site by linking your account from the Site to any of your social networking accounts, you automatically grant, and you represent and warrant that you have the right to grant, to us an unrestricted, unlimited, irrevocable, perpetual, non-exclusive, transferable, royalty-free, fully-paid, worldwide right, and license to host, use, copy, reproduce, disclose, sell, resell, publish, broadcast, retitle, archive, store, cache, publicly perform, publicly display, reformat, translate, transmit, excerpt (in whole or in part), and distribute such Contributions (including, without limitation, your image and voice) for any purpose, commercial, advertising, or otherwise, and to prepare derivative works of, or incorporate into other works, such Contributions, and grant and authorize sublicenses of the foregoing. The use and distribution may occur in any media formats and through any media channels.
This license will apply to any form, media, or technology now known or hereafter developed, and includes our use of your name, company name, and franchise name, as applicable, and any of the trademarks, service marks, trade names, logos, and personal and commercial images you provide. You waive all moral rights in your Contributions, and you warrant that moral rights have not otherwise been asserted in your Contributions.
We do not assert any ownership over your Contributions. You retain full ownership of all of your Contributions and any intellectual property rights or other proprietary rights associated with your Contributions. We are not liable for any statements or representations in your Contributions provided by you in any area on the Site. You are solely responsible for your Contributions to the Site and you expressly agree to exonerate us from any and all responsibility and to refrain from any legal action against us regarding your Contributions.
We have the right, in our sole and absolute discretion, (1) to edit, redact, or otherwise change any Contributions; (2) to re-categorize any Contributions to place them in more appropriate locations on the Site; and (3) to pre-screen or delete any Contributions at any time and for any reason, without notice. We have no obligation to monitor your Contributions.
### Guidelines For Reviews
We may provide you areas on the Site to leave reviews or ratings. When posting a review, you must comply with the following criteria: (1) you should have firsthand experience with the person/entity being reviewed; (2) your reviews should not contain offensive profanity, or abusive, racist, offensive, or hate language; (3) your reviews should not contain discriminatory references based on religion, race, gender, national origin, age, marital status, sexual orientation, or disability; (4) your reviews should not contain references to illegal activity; (5) you should not be affiliated with competitors if posting negative reviews; (6) you should not make any conclusions as to the legality of conduct; (7) you may not post any false or misleading statements; and (8) you may not organize a campaign encouraging others to post reviews, whether positive or negative.
We may accept, reject, or remove reviews in our sole discretion. We have absolutely no obligation to screen reviews or to delete reviews, even if anyone considers reviews objectionable or inaccurate. Reviews are not endorsed by us, and do not necessarily represent our opinions or the views of any of our affiliates or partners. We do not assume liability for any review or for any claims, liabilities, or losses resulting from any review. By posting a review, you hereby grant to us a perpetual, non-exclusive, worldwide, royalty-free, fully-paid, assignable, and sublicensable right and license to reproduce, modify, translate, transmit by any means, display, perform, and/or distribute all content relating to reviews.
### Social Media
As part of the functionality of the Site, you may link your account with online accounts you have with third-party service providers (each such account, a “Third-Party Account”) by either: (1) providing your Third-Party Account login information through the Site; or (2) allowing us to access your Third-Party Account, as is permitted under the applicable terms and conditions that govern your use of each Third-Party Account. You represent and warrant that you are entitled to disclose your Third-Party Account login information to us and/or grant us access to your Third-Party Account, without breach by you of any of the terms and conditions that govern your use of the applicable Third-Party Account, and without obligating us to pay any fees or making us subject to any usage limitations imposed by the third-party service provider of the Third-Party Account. By granting us access to any Third-Party Accounts, you understand that (1) we may access, make available, and store (if applicable) any content that you have provided to and stored in your Third-Party Account (the “Social Network Content”) so that it is available on and through the Site via your account, including without limitation any friend lists and (2) we may submit to and receive from your Third-Party Account additional information to the extent you are notified when you link your account with the Third-Party Account.
Depending on the Third-Party Accounts you choose and subject to the privacy settings that you have set in such Third-Party Accounts, personally identifiable information that you post to your Third-Party Accounts may be available on and through your account on the Site. Please note that if a Third-Party Account or associated service becomes unavailable or our access to such Third-Party Account is terminated by the third-party service provider, then Social Network Content may no longer be available on and through the Site. You will have the ability to disable the connection between your account on the Site and your Third-Party Accounts at any time.
PLEASE NOTE THAT YOUR RELATIONSHIP WITH THE THIRD-PARTY SERVICE PROVIDERS ASSOCIATED WITH YOUR THIRD-PARTY ACCOUNTS IS GOVERNED SOLELY BY YOUR AGREEMENT(S) WITH SUCH THIRD-PARTY SERVICE PROVIDERS. We make no effort to review any Social Network Content for any purpose, including but not limited to, for accuracy, legality, or non-infringement, and we are not responsible for any Social Network Content. You acknowledge and agree that we may access your email address book associated with a Third-Party Account and your contacts list stored on your mobile device or tablet computer solely for purposes of identifying and informing you of those contacts who have also registered to use the Site. You can deactivate the connection between the Site and your Third-Party Account by contacting us using the contact information below or through your account settings (if applicable). We will attempt to delete any information stored on our servers that was obtained through such Third-Party Account, except the username and profile picture that become associated with your account.
### Submissions
You acknowledge and agree that any questions, comments, suggestions, ideas, feedback, or other information regarding the Site (“Submissions”) provided by you to us are non-confidential and shall become our sole property. We shall own exclusive rights, including all intellectual property rights, and shall be entitled to the unrestricted use and dissemination of these Submissions for any lawful purpose, commercial or otherwise, without acknowledgment or compensation to you. You hereby waive all moral rights to any such Submissions, and you hereby warrant that any such Submissions are original with you or that you have the right to submit such Submissions. You agree there shall be no recourse against us for any alleged or actual infringement or misappropriation of any proprietary right in your Submissions.
### U.S. Government Rights
Our services are “commercial items” as defined in Federal Acquisition Regulation (“FAR”) 2.101. If our services are acquired by or on behalf of any agency not within the Department of Defense (“DOD”), our services are subject to the terms of these Terms of Use in accordance with FAR 12.212 (for computer software) and FAR 12.211 (for technical data). If our services are acquired by or on behalf of any agency within the Department of Defense, our services are subject to the terms of these Terms of Use in accordance with Defense Federal Acquisition Regulation (“DFARS”) 227.7202‑3. In addition, DFARS 252.227‑7015 applies to technical data acquired by the DOD. This U.S. Government Rights clause is in lieu of, and supersedes, any other FAR, DFARS, or other clause or provision that addresses government rights in computer software or technical data under these Terms of Use.
### Site Management
We reserve the right, but not the obligation, to: (1) monitor the Site for violations of these Terms of Use; (2) take appropriate legal action against anyone who, in our sole discretion, violates the law or these Terms of Use, including without limitation, reporting such user to law enforcement authorities; (3) in our sole discretion and without limitation, refuse, restrict access to, limit the availability of, or disable (to the extent technologically feasible) any of your Contributions or any portion thereof; (4) in our sole discretion and without limitation, notice, or liability, to remove from the Site or otherwise disable all files and content that are excessive in size or are in any way burdensome to our systems; and (5) otherwise manage the Site in a manner designed to protect our rights and property and to facilitate the proper functioning of the Site.
### Privacy Notice
We care about data privacy and security. Please review our [Privacy Notice](https://legal.xano.com/privacy-notice). By using the Site, you agree to be bound by our [Privacy Notice](https://legal.xano.com/privacy-notice), which is incorporated into these Terms & Conditions. Please be advised the Site is hosted in the United States. If you access the Site from any other region of the world with laws or other requirements governing personal data collection, use, or disclosure that differ from applicable laws in the United States, then through your continued use of the Site, you are transferring your data to the United States, and you agree to have your data transferred to and processed in the United States. [READ MORE](https://legal.xano.com/privacy-policy).
### Cookie Policy
Cookies are small data files that are placed on your computer or mobile device when you visit a website. Cookies are widely used by website owners in order to make their websites work, or to work more efficiently, as well as to provide reporting information. Please review our [Cookie Policy](https://legal.xano.com/cookie-policy). By using the Site, you agree to be bound by our [Cookie Policy](https://legal.xano.com/cookie-policy), which is incorporated into these Terms & Conditions. It explains what these technologies are and why we use them, as well as your rights to control our use of them. [READ MORE](https://legal.xano.com/cookie-policy).
### Copyright Infringements
We respect the intellectual property rights of others. If you believe that any material available on or through the Site infringes upon any copyright you own or control, please immediately notify us using the contact information provided below (a “Notification”). A copy of your Notification will be sent to the person who posted or stored the material addressed in the Notification. Please be advised that pursuant to applicable law you may be held liable for damages if you make material misrepresentations in a Notification. Thus, if you are not sure that material located on or linked to by the Site infringes your copyright, you should consider first contacting an attorney.
### Term And Termination
These Terms of Use shall remain in full force and effect while you use the Site. WITHOUT LIMITING ANY OTHER PROVISION OF THESE TERMS OF USE, WE RESERVE THE RIGHT TO, IN OUR SOLE DISCRETION AND WITHOUT NOTICE OR LIABILITY, DENY ACCESS TO AND USE OF THE SITE (INCLUDING BLOCKING CERTAIN IP ADDRESSES), TO ANY PERSON FOR ANY REASON OR FOR NO REASON, INCLUDING WITHOUT LIMITATION FOR BREACH OF ANY REPRESENTATION, WARRANTY, OR COVENANT CONTAINED IN THESE TERMS OF USE OR OF ANY APPLICABLE LAW OR REGULATION. WE MAY TERMINATE YOUR USE OR PARTICIPATION IN THE SITE OR DELETE YOUR ACCOUNT AND ANY CONTENT OR INFORMATION THAT YOU POSTED AT ANY TIME, WITHOUT WARNING, IN OUR SOLE DISCRETION.
If we terminate or suspend your account for any reason, you are prohibited from registering and creating a new account under your name, a fake or borrowed name, or the name of any third party, even if you may be acting on behalf of the third party. In addition to terminating or suspending your account, we reserve the right to take appropriate legal action, including without limitation pursuing civil, criminal, and injunctive redress.
### Modifications And Interruptions
We reserve the right to change, modify, or remove the contents of the Site at any time or for any reason at our sole discretion without notice. However, we have no obligation to update any information on our Site. We also reserve the right to modify or discontinue all or part of the Site without notice at any time. We will not be liable to you or any third party for any modification, price change, suspension, or discontinuance of the Site.
We cannot guarantee the Site will be available at all times. We may experience hardware, software, or other problems or need to perform maintenance related to the Site, resulting in interruptions, delays, or errors. We reserve the right to change, revise, update, suspend, discontinue, or otherwise modify the Site at any time or for any reason without notice to you. You agree that we have no liability whatsoever for any loss, damage, or inconvenience caused by your inability to access or use the Site during any downtime or discontinuance of the Site. Nothing in these Terms of Use will be construed to obligate us to maintain and support the Site or to supply any corrections, updates, or releases in connection therewith.
### Governing Law
These Terms of Use and your use of the Site are governed by and construed in accordance with the laws of the State of California applicable to agreements made and to be entirely performed within the State of California, without regard to its conflict of law principles.
### Dispute Resolution
#### Informal Negotiations
To expedite resolution and control the cost of any dispute, controversy, or claim related to these Terms of Use (each a “Dispute” and collectively, the “Disputes”) brought by either you or us (individually, a “Party” and collectively, the “Parties”), the Parties agree to first attempt to negotiate any Dispute (except those Disputes expressly provided below) informally for at least thirty (30) days before initiating arbitration. Such informal negotiations commence upon written notice from one Party to the other Party.
#### Binding Arbitration
If the Parties are unable to resolve a Dispute through informal negotiations, the Dispute (except those Disputes expressly excluded below) will be finally and exclusively resolved by binding arbitration. YOU UNDERSTAND THAT WITHOUT THIS PROVISION, YOU WOULD HAVE THE RIGHT TO SUE IN COURT AND HAVE A JURY TRIAL. The arbitration shall be commenced and conducted under the Commercial Arbitration Rules of the American Arbitration Association (“AAA”) and, where appropriate, the AAA’s Supplementary Procedures for Consumer Related Disputes (“AAA Consumer Rules”), both of which are available at the AAA website [www.adr.org](http://www.adr.org/). Your arbitration fees and your share of arbitrator compensation shall be governed by the AAA Consumer Rules and, where appropriate, limited by the AAA Consumer Rules. The arbitration may be conducted in person, through the submission of documents, by phone, or online. The arbitrator will make a decision in writing, but need not provide a statement of reasons unless requested by either Party. The arbitrator must follow applicable law, and any award may be challenged if the arbitrator fails to do so. Except where otherwise required by the applicable AAA rules or applicable law, the arbitration will take place in United States, California. Except as otherwise provided herein, the Parties may litigate in court to compel arbitration, stay proceedings pending arbitration, or to confirm, modify, vacate, or enter judgment on the award entered by the arbitrator.
If for any reason, a Dispute proceeds in court rather than arbitration, the Dispute shall be commenced or prosecuted in the state and federal courts located in United States, California, and the Parties hereby consent to, and waive all defenses of lack of personal jurisdiction, and forum non conveniens with respect to venue and jurisdiction in such state and federal courts. Application of the United Nations Convention on Contracts for the International Sale of Goods and the Uniform Computer Information Transaction Act (UCITA) are excluded from these Terms of Use.
In no event shall any Dispute brought by either Party related in any way to the Site be commenced more than one (1) years after the cause of action arose. If this provision is found to be illegal or unenforceable, then neither Party will elect to arbitrate any Dispute falling within that portion of this provision found to be illegal or unenforceable and such Dispute shall be decided by a court of competent jurisdiction within the courts listed for jurisdiction above, and the Parties agree to submit to the personal jurisdiction of that court.
#### Restrictions
The Parties agree that any arbitration shall be limited to the Dispute between the Parties individually. To the full extent permitted by law, (a) no arbitration shall be joined with any other proceeding; (b) there is no right or authority for any Dispute to be arbitrated on a class-action basis or to utilize class action procedures; and (c) there is no right or authority for any Dispute to be brought in a purported representative capacity on behalf of the general public or any other persons.
#### Exceptions to Informal Negotiations and Arbitration
The Parties agree that the following Disputes are not subject to the above provisions concerning informal negotiations and binding arbitration: (a) any Disputes seeking to enforce or protect, or concerning the validity of, any of the intellectual property rights of a Party; (b) any Dispute related to, or arising from, allegations of theft, piracy, invasion of privacy, or unauthorized use; and (c) any claim for injunctive relief. If this provision is found to be illegal or unenforceable, then neither Party will elect to arbitrate any Dispute falling within that portion of this provision found to be illegal or unenforceable and such Dispute shall be decided by a court of competent jurisdiction within the courts listed for jurisdiction above, and the Parties agree to submit to the personal jurisdiction of that court.
### Corrections
There may be information on the Site that contains typographical errors, inaccuracies, or omissions, including descriptions, pricing, availability, and various other information. We reserve the right to correct any errors, inaccuracies, or omissions and to change or update the information on the Site at any time, without prior notice.
### Disclaimer
THE SITE IS PROVIDED ON AN AS-IS AND AS-AVAILABLE BASIS. YOU AGREE THAT YOUR USE OF THE SITE AND OUR SERVICES WILL BE AT YOUR SOLE RISK. TO THE FULLEST EXTENT PERMITTED BY LAW, WE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, IN CONNECTION WITH THE SITE AND YOUR USE THEREOF, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. WE MAKE NO WARRANTIES OR REPRESENTATIONS ABOUT THE ACCURACY OR COMPLETENESS OF THE SITE’S CONTENT OR THE CONTENT OF ANY WEBSITES LINKED TO THE SITE AND WE WILL ASSUME NO LIABILITY OR RESPONSIBILITY FOR ANY (1) ERRORS, MISTAKES, OR INACCURACIES OF CONTENT AND MATERIALS, (2) PERSONAL INJURY OR PROPERTY DAMAGE, OF ANY NATURE WHATSOEVER, RESULTING FROM YOUR ACCESS TO AND USE OF THE SITE, (3) ANY UNAUTHORIZED ACCESS TO OR USE OF OUR SECURE SERVERS AND/OR ANY AND ALL PERSONAL INFORMATION AND/OR FINANCIAL INFORMATION STORED THEREIN, (4) ANY INTERRUPTION OR CESSATION OF TRANSMISSION TO OR FROM THE SITE, (5) ANY BUGS, VIRUSES, TROJAN HORSES, OR THE LIKE WHICH MAY BE TRANSMITTED TO OR THROUGH THE SITE BY ANY THIRD PARTY, AND/OR (6) ANY ERRORS OR OMISSIONS IN ANY CONTENT AND MATERIALS OR FOR ANY LOSS OR DAMAGE OF ANY KIND INCURRED AS A RESULT OF THE USE OF ANY CONTENT POSTED, TRANSMITTED, OR OTHERWISE MADE AVAILABLE VIA THE SITE. WE DO NOT WARRANT, ENDORSE, GUARANTEE, OR ASSUME RESPONSIBILITY FOR ANY PRODUCT OR SERVICE ADVERTISED OR OFFERED BY A THIRD PARTY THROUGH THE SITE, ANY HYPERLINKED WEBSITE, OR ANY WEBSITE OR MOBILE APPLICATION FEATURED IN ANY BANNER OR OTHER ADVERTISING, AND WE WILL NOT BE A PARTY TO OR IN ANY WAY BE RESPONSIBLE FOR MONITORING ANY TRANSACTION BETWEEN YOU AND ANY THIRD-PARTY PROVIDERS OF PRODUCTS OR SERVICES. AS WITH THE PURCHASE OF A PRODUCT OR SERVICE THROUGH ANY MEDIUM OR IN ANY ENVIRONMENT, YOU SHOULD USE YOUR BEST JUDGMENT AND EXERCISE CAUTION WHERE APPROPRIATE.
### Limitations Of Liability
IN NO EVENT WILL WE OR OUR DIRECTORS, EMPLOYEES, OR AGENTS BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, EXEMPLARY, INCIDENTAL, SPECIAL, OR PUNITIVE DAMAGES, INCLUDING LOST PROFIT, LOST REVENUE, LOSS OF DATA, OR OTHER DAMAGES ARISING FROM YOUR USE OF THE SITE, EVEN IF WE HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED HEREIN, OUR LIABILITY TO YOU FOR ANY CAUSE WHATSOEVER AND REGARDLESS OF THE FORM OF THE ACTION, WILL AT ALL TIMES BE LIMITED TO THE LESSER OF THE AMOUNT PAID, IF ANY, BY YOU TO US DURING THE SIX (6) MONTH PERIOD PRIOR TO ANY CAUSE OF ACTION ARISING OR \$600.00 USD. CERTAIN US STATE LAWS AND INTERNATIONAL LAWS DO NOT ALLOW LIMITATIONS ON IMPLIED WARRANTIES OR THE EXCLUSION OR LIMITATION OF CERTAIN DAMAGES. IF THESE LAWS APPLY TO YOU, SOME OR ALL OF THE ABOVE DISCLAIMERS OR LIMITATIONS MAY NOT APPLY TO YOU, AND YOU MAY HAVE ADDITIONAL RIGHTS.
### Indemnification
You agree to defend, indemnify, and hold us harmless, including our subsidiaries, affiliates, and all of our respective officers, agents, partners, and employees, from and against any loss, damage, liability, claim, or demand, including reasonable attorneys’ fees and expenses, made by any third party due to or arising out of: (1) your Contributions; (2) use of the Site; (3) breach of these Terms of Use; (4) any breach of your representations and warranties set forth in these Terms of Use; (5) your violation of the rights of a third party, including but not limited to intellectual property rights; or (6) any overt harmful act toward any other user of the Site with whom you connected via the Site. Notwithstanding the foregoing, we reserve the right, at your expense, to assume the exclusive defense and control of any matter for which you are required to indemnify us, and you agree to cooperate, at your expense, with our defense of such claims. We will use reasonable efforts to notify you of any such claim, action, or proceeding which is subject to this indemnification upon becoming aware of it.
### User Data
We will maintain certain data that you transmit to the Site for the purpose of managing the performance of the Site, as well as data relating to your use of the Site. Although we perform regular routine backups of data, you are solely responsible for all data that you transmit or that relates to any activity you have undertaken using the Site. You agree that we shall have no liability to you for any loss or corruption of any such data, and you hereby waive any right of action against us arising from any such loss or corruption of such data.
### Electronic Communications, Transactions, And Signatures
Visiting the Site, sending us emails, and completing online forms constitute electronic communications. You consent to receive electronic communications, and you agree that all agreements, notices, disclosures, and other communications we provide to you electronically, via email and on the Site, satisfy any legal requirement that such communication be in writing. Additionally, if you voluntarily provide your telephone number to us, you consent to Xano initiating telephone communication with you for service-related purposes. Details regarding the use of your telephone number are further outlined in our [Privacy Notice](https://legal.xano.com/privacy-notice).
YOU HEREBY AGREE TO THE USE OF ELECTRONIC SIGNATURES, CONTRACTS, ORDERS, AND OTHER RECORDS, AND TO ELECTRONIC DELIVERY OF NOTICES, POLICIES, AND RECORDS OF TRANSACTIONS INITIATED OR COMPLETED BY US OR VIA THE SITE. You hereby waive any rights or requirements under any statutes, regulations, rules, ordinances, or other laws in any jurisdiction which require an original signature or delivery or retention of non-electronic records, or to payments or the granting of credits by any means other than electronic means.
### California Users And Residents
If any complaint with us is not satisfactorily resolved, you can contact the Complaint Assistance Unit of the Division of Consumer Services of the California Department of Consumer Affairs in writing at 1625 North Market Blvd., Suite N 112, Sacramento, California 95834 or by telephone at (800) 952-5210 or (916) 445-1254.
### Miscellaneous
These Terms of Use and any policies or operating rules posted by us on the Site or in respect to the Site constitute the entire agreement and understanding between you and us. Our failure to exercise or enforce any right or provision of these Terms of Use shall not operate as a waiver of such right or provision. These Terms of Use operate to the fullest extent permissible by law. We may assign any or all of our rights and obligations to others at any time. We shall not be responsible or liable for any loss, damage, delay, or failure to act caused by any cause beyond our reasonable control. If any provision or part of a provision of these Terms of Use is determined to be unlawful, void, or unenforceable, that provision or part of the provision is deemed severable from these Terms of Use and does not affect the validity and enforceability of any remaining provisions.
Except for the Referral Agreement, there is no implied joint venture, partnership, employment or agency relationship created between you and us as a result of these Terms of Use or use of the Site. You agree that these Terms of Use will not be construed against us by virtue of having drafted them. You hereby waive any and all defenses you may have based on the electronic form of these Terms of Use and the lack of signing by the parties hereto to execute these Terms of Use.
### Referral Agreement
This agreement (“Agreement”) is entered between Xano. (“Company”), and Referral partner (“Referrer”), using the name and address submitted when completing the referral partner application.
Whereas, Referrer has experience, business relationships, and network contacts within its industry, stands in a position to act as a Referrer with Xano;
Whereas, Referrer will participate in Xano’s lead referral program in which Referrer will provide Xano with a potential customer identified by Referrer (“Leads”) in exchange for which Xano will pay certain commissions as described below.
Whereas, Xano desires to engage the Referrer for the purposes of marketing and selling Xano’s Software and Services; and
Therefore, in consideration of the following conditions set for the in this Agreement, the parties agree to the following.
#### Defined Terms
“Actively Participate” shall mean Referrer’s active engagement in the introduction of a Lead to Xano through an email; an in-person introduction; a telephone introduction; through a joint sales call; via the Xano shopping cart (most common method), or by using the referral form located at the Xano partner program website.
“Material Support” shall mean Referrer’s continued support of Xano through the sales process
“Commissionable Lead” shall mean a Lead for which Referrer is eligible under Section 2.a. to be paid a commission because the Lead has become a customer of Xano by executing a Xano Service Agreement for use of a Xano Service.
“Xano Lead Form” or “RLF” shall mean a standard form generated by Xano to be used by Referrer to identify a referred Lead for purposes of qualifying the Lead as a Commissionable Lead. Some leads will purchase via the Xano shopping cart.
“Lead Referral Date” shall mean the date Xano receives the RLF.
“Service” shall mean the on-line “Software as a Service” business application known as Xano or similar or successor product, which Xano licenses to Customers.
Relationship 2. Referrer is not an agent or legal representative of Xano for any purpose, and has no authority to act for, bind or commit Xano.
2.1 Referrer has no authority to make any commitment on behalf of Xano with respect to quantities, delivery, modifications, interfacing capability, suitability of software or suitability in specific applications. Reseller has no authority to modify the warranty offered with Xano products.
1. Referrer will not represent itself in any way that implies Referrer is an agent or branch of Xano. Referrer will immediately change or discontinue any representation or business practice found to be misleading or deceptive by Xano immediately upon notice from Xano.
Term, Limitations, Termination 3.1. The term of this Agreement is twelve (12) months from the date of acceptance by Referrer and Xano. This Agreement shall automatically renew on each subsequent year for a one-year term, unless it is terminated earlier in accordance with this Agreement.
3.2. Xano or Referrer may terminate this Agreement without cause at any time upon thirty (30) days written notice or with cause at any time upon fifteen (15) days written notice, except that neither the expiration nor earlier termination of this Agreement shall release either party from any obligation which has accrued as of the date of termination.
3.3 Xano may, from time to time, give Referrer written notice of amendments to this Agreement. Any such amendment will automatically become a part of this Agreement thirty (30) days from the date of the notice, unless otherwise specified in the notice.
#### TERMS AND CONDITIONS OF LEAD REFERRAL AND ACCEPTANCE
Referrer’s Identification and Referral of Leads: Referrer acknowledges and agrees that in order for a Lead to qualify as a Commissionable Lead, the following must have occurred: Referrer must have provided valid details of the Commissionable Lead to a Xano and
Referrer must have timely documented the introduction of the Lead on a Xano Lead Form (“RLF”) and must have submitted the completed RLF to Xano for review; and
Xano must have reviewed Referrer’s RLF and accepted the Lead as commissionable (i.e., not rejected the Lead for any of the reasons stated in the Exclusions section below, or otherwise); or
Customer has completed an online order via the Xano shopping cart (using the Xano referral link that contains Referrer’s referral code).
Referrer acknowledges and agrees that no commission will be paid to Referrer by Xano for the referral of a Lead:
that was an existing customer of Xano’s at the time of the referral; or
both the referrer and referee are the same entity or person; or
with whom Xano was already involved in preliminary or advanced discussions relating toward the sale of a license to Lead (as of the date of the RLF); or
for whom a RLF (or similar document) has previously been submitted to Xano by Referrer or any other third party; or
Referrer acknowledges that it shall be solely responsible for and shall bear all costs associated with Referrer’s development of any Leads for referral to Xano.
Xano’s Obligations Upon Lead Referral
Xano hereby authorizes Referrer to refer Leads to Xano in exchange for the remuneration listed in Exhibit “A.”
Xano shall upon submission of a RLF from Referrer promptly review the RLF to determine whether to accept or reject the Lead as commissionable under the conditions of lead referral and acceptance section above, or other commercially reasonable reason as determined by Xano.
Xano will notify Referrer within 24-48 hours during business days (“Notification Date”) of receipt of the RLF as to whether the Lead submitted by Referrer to Xano is commissionable.
Upon acceptance of a Lead as commissionable, Xano shall be solely responsible for all costs associated with the sale of a License to said Lead.
Mutual Obligations Re: Lead Development/Sale
Each Party will cooperate with the other to develop and execute a strategy to best serve the needs of the Commissionable Lead, including how the Parties will work separately or together, if at all, regarding the Lead.
Each Party will, upon request of the other Party, provide the other with non-confidential information it has regarding a Lead in order to assist the other party in (i) verifying the eligibility of the Lead as commissionable; and/or (ii) successfully soliciting the Lead to purchase Xano products. This can be relayed via email, or by phone, but it is typically referred within the Online Referral Form found at the Xano partner program website. It does not apply if the referral completed an order within the Xano shopping cart.
Each Party will, upon request of the other Party, in its reasonable discretion, provide the other Party with information regarding its services and/or products. Such information shall include sales and marketing materials and informal training. Any training provided under this Section shall be conducted at mutually agreed times and places and shall be conducted in accordance with the training Party’s discretion.
Each Party will conduct all of its business in its own name and in a businesslike and professional manner. Referrer will not make any representations or guarantees concerning the Xano Services. Product guarantees are contained within the Xano end user license agreement.
#### COMMISSIONS/REFERRAL FEES
Subject to the terms and conditions of this Agreement, Xano will pay Referrer a commission as determined by schedule set forth in Exhibit “A” for each Commissionable Lead referred by Referrer to Xano in compliance with the requirements of Section 2 above, that enters into a License Agreement with Xano. The payment of commissions will be made in U.S. Dollars. Referrer shall be solely responsible for payment of any and all national, state, and local taxes and charges arising from or imposed on the payments made to Referrer by Xano.
Payment Timing. Commissions under this Section shall be due no later than the last day of the “30-day period” following the “30-day period” after Xano actually receives the applicable payment of fees from the Commissionable Lead, but in no case earlier than the expiration of any return period agreed to by Xano and the Commissionable Lead.
This agreement is accepted when you click “submit” during the referral program application process.
#### EXHIBIT A – PARTNER COMMISSION FORMULA
For each Commissionable Lead, Xano will pay Referrer as specified below, of the Monthly Contract Value for Xano’s Software as a Service that is actually received and earned by Xano from the Commissionable Lead over the first year.
All actual amounts are redacted for confidentiality within this preview version of the agreement. Amounts can be obtain via phone or email from the partner manager, but will also be contained in the referral partner acceptance email.
### Contact Us
In order to resolve a complaint regarding the Site or to receive further information regarding use of the Site, please contact us at:
**Xano, Inc.**\
21600 Oxnard Street, Suite 910\
Woodland Hills, California 91367\
United States
Phone: [+1 (818) 275-4870](tel:18182754870)\
[support@xano.com](mailto:support@xano.com)
# AI Terms
Source: https://docs.xano.com/legal/ai-terms
## Xano AI Terms
These Xano AI Terms (“AI Terms”) apply to your access and use of Xano AI (as defined below). The AI Terms are a part of your agreement with Xano, as outlined in your Xano Terms of Service or any applicable master subscription agreement between you and Xano (the “Service Terms”). Capitalized terms not defined here will have the same meaning as in your Service Terms. In case of a conflict between these AI Terms and your Service Terms, these AI Terms will govern.
## Introducing Xano AI
"Xano AI" or "AI Feature" refers to the features, agents, and functionality available within Xano that utilize generative artificial intelligence models. Xano AI is powered by the third-party AI platform [Google Gemini AI](https://ai.google.dev/aistudio), which may be updated periodically (“Third-Party AI Provider(s)”). The AI processing is conducted using a large language model (LLM), specifically Gemini Flash Lite, Gemini Flash, and Gemini Pro, which generate responses based on user input. These AI-generated outputs are provided primarily for illustrative and testing purposes. By agreeing to and complying with these terms, you are granted a non-exclusive, revocable, non-transferable, limited right to access and use Xano AI in accordance with your Service Terms and these AI Terms.
Subject to your compliance with these AI Terms, Xano grants you a non-exclusive, revocable, non-transferable, and limited right to access and use Xano AI in accordance with your Service Terms, including these AI Terms.
## Interacting With Xano AI: Input & Output
When using Xano AI, you may provide text, data, prompts, or other forms of input for processing ("Input"). In turn, you will receive output generated by the AI based on your Input ("Output"). Input and Output are collectively considered your data and part of the broader category of "Customer Data."
By using Xano AI, you acknowledge and agree that any Input you provide may be analyzed by Xano to generate personalized recommendations, identify potential solutions, or suggest new features. This analysis is conducted in compliance with applicable data protection laws, including the [General Data Protection Regulation](https://gdpr.eu/) and the [California Consumer Privacy Act](https://oag.ca.gov/privacy/ccpa). For further details on our data practices, please review our [Privacy Notice](https://legal.xano.com/privacy-notice).
## Guidelines For Responsible Use
You are fully responsible for the content and legality of the Input you provide and the Output you receive when using Xano AI.
You represent and warrant that both your Input and Output will comply with all:
* Applicable laws;
* [Terms & Conditions](/legal), including these AI Terms; and
* [Prohibited Activities](/legal#prohibited-activities)
Furthermore, you agree to adhere to the applicable terms and policies of any Third-Party AI Provider [terms](https://ai.google.dev/gemini-api/terms). Violations may result in suspension or termination of your access to Xano AI.
## User Responsibilities & AI Output Limitations
Due to the nature of machine learning models and technologies, Xano AI may produce Output that is not unique and may be similar or identical to Output provided to other users. Xano AI does not retrieve real-time information, and the Output may not reflect events or changes after the model was last trained. Xano AI may provide inaccurate, incomplete, or outdated information.
\
You are encouraged to provide sufficient contextual information about your projects to improve the relevance and usefulness of Output. However, you should avoid submitting sensitive, confidential, or proprietary information, including but not limited to intellectual property, personally identifiable information (PII), protected health information (PHI), or other regulated data, unless you have implemented appropriate safeguards and have the legal right to do so.
\
Therefore, it is your responsibility to independently verify the factual accuracy, completeness, and relevance of the Output before using it for decision-making or operational purposes. You are solely responsible for reviewing, validating, and testing any Output, including but not limited to code, logic, and application development recommendations, prior to implementation or deployment.
\
Xano makes no representations or warranties regarding the accuracy, reliability, or fitness for a particular purpose of any Output and disclaims any liability for damages or losses arising from the use of such Output, including but not limited to errors in code, application behavior, or system performance.
## All Enhancement
Your usage of Xano AI does not confer upon Xano any additional rights to your Customer Data beyond those outlined in your Service Agreement. Xano does not use your Input or Output to train its AI models or allow others to do so without your explicit consent.
## Retention & Use Of Data
Third-Party AI Providers will neither (a) log Input or Output for human examination nor (b) store or retain Input or Output. However, Third-Party AI Providers may collect and utilize metadata related to Xano AI usage strictly for purposes such as billing, safety, and compliance.
Xano may engage subprocessors to support, analyze, and improve its AI-related features and services. This includes the use of Braintrust, a third-party service provider, to process certain data transmitted through AI Feature usage. Data processed by Braintrust may include your prompts and associated workspace data, such as functions, API keys, and XanoScript code, that are sent to AI Providers in connection with your use of AI Features. Such data is processed in a pseudonymous manner; however, depending on Inputs, it may contain sensitive information. This processing is undertaken to support compliance efforts, monitor performance, and improve the quality, reliability, and functionality of Xano’s AI features. You are responsible for the content you submit and should avoid including sensitive personal data in your Inputs.
\
You may opt out of AI Features that involve such processing at any time through your workspace settings, provided you are on a paid Xano plan. Disabling these features will prevent associated data from being processed by such subprocessors.
## Privacy & Data Processing
If your Customer Data includes personal information (as defined in any applicable data protection agreement between us), you agree that Xano and its subprocessors, including the listed Third-Party AI Providers, may process this data as needed to provide Xano AI and its related services. The list of subprocessors can be found at [/legal/xano-subprocessors](/legal/xano-subprocessors).
## Service Availability & Suspension
Xano reserves the right to suspend or terminate your access to Xano AI if it reasonably believes your use violates these AI Terms, poses a risk to Xano or others, or if required by a Third-Party AI Provider. Xano may also suspend Xano AI if required by legal, regulatory, or compliance obligations. Xano does not guarantee continuous availability of Xano AI, and any downtime will not count towards any service level agreement commitments.
## Exploring Beta Features
From time to time, Xano may offer beta or experimental versions of Xano AI features (“Beta Features”). These Beta Features are provided on an “as is” basis without any warranty, performance guarantee, or liability, and may be discontinued at any time without notice. Xano is under no obligation to provide support or maintain the Beta AI Features, and their discontinuation may result in limited access to certain Customer Data.
## AI Terms Modifications
Xano may periodically update these AI Terms. When changes occur, the "Last Updated" date will be revised accordingly. For material changes, Xano will provide reasonable notice through email or platform notifications. Your continued use of Xano AI after changes become effective constitutes your acceptance of the revised AI Terms. If you do not agree with the new terms, you must disable Xano AI and stop using it before the changes take effect.
## Indemnification Clause
You agree to indemnify, defend, and hold harmless Xano, its affiliates, and its third-party AI providers from and against any claims, damages, losses, liabilities, costs, and expenses (including reasonable attorneys' fees) arising out of or related to your breach of these AI Terms, misuse of Xano AI, or violations of any applicable law or regulation. This indemnification obligation will survive the termination of your access to Xano AI.
## Data Protection & Privacy
Xano collaborates with trusted third-party providers who assist in delivering and enhancing our AI services. Each subprocessor undergoes regular security and compliance reviews to make sure they meet Xano's standards for data protection and privacy, including compliance with regulations such as the GDPR.
## User-Connected AI Models & Third-Party Services
Xano may provide functionality that enables you to connect your own third-party artificial intelligence models, large language models (“LLMs”), or other external AI services (collectively, “Connected Third-Party AI Services”) to your Xano workspace, including through the use of API keys or other authentication mechanisms. Such integrations are configured and controlled solely by you.
\
Xano does not own, operate, or control any Connected Third-Party AI Services, and makes no representations or warranties regarding their security, availability, compliance, or data handling practices. You acknowledge and agree that any data transmitted to or processed by such Connected Third-Party AI Services is governed by the terms and policies of the applicable third party.
\
You are solely responsible for ensuring that appropriate security configurations, access controls, and compliance measures are implemented within your Connected Third-Party AI Service accounts prior to connecting them to Xano, including but not limited to the proper management of API keys and credentials. Xano shall not be responsible or liable for any unauthorized access, data exposure, loss, or other damages arising from or related to the use of Connected Third-Party AI Services.
### Contact Us
In order to resolve a complaint regarding the AI or to receive further information regarding use of AI, please contact us at:
**Xano, Inc.**\
21600 Oxnard Street, Suite 910\
Woodland Hills, California 91367\
United States
Phone: [+1 (818) 275-4870](tel:8182937431)\
[support@xano.com](mailto:support@xano.com)
# Cookie Policy
Source: https://docs.xano.com/legal/cookie-policy
This Cookie Policy explains how Xano, Inc. ("Company", "we", "us", and "our") uses cookies and similar technologies to recognize you when you visit our websites at [https://www.xano.com](https://www.xano.com/), ("Websites"). It explains what these technologies are and why we use them, as well as your rights to control our use of them.
We use cookies to personalize your experience, analyze user trends, and improve the Xano Platform. These cookies allow us to collect information such as your device and browser type, time spent on our website, pages visited, geographic location, and other data. You can alter the configuration of your browser to refuse to accept cookies, but it is possible that doing so may cause limited functionality and may impact certain features of the services offered or your experience in using the Xano platform.
### **What are cookies?**
Cookies are small data files that are placed on your computer or mobile device when you visit a website. Cookies are widely used by website owners in order to make their websites work, or to work more efficiently, as well as to provide reporting information.
Cookies set by the website owner (in this case, Xano, Inc.) are called "first party cookies". Cookies set by parties other than the website owner are called "third party cookies". Third party cookies enable third party features or functionality to be provided on or through the website (e.g. like advertising, interactive content and analytics). The parties that set these third party cookies can recognize your computer both when it visits the website in question and also when it visits certain other websites.
### **Why do we use cookies?**
We use first and third party cookies for several reasons. Some cookies are required for technical reasons in order for our Websites to operate, and we refer to these as "essential" or "strictly necessary" cookies. Other cookies also enable us to track and target the interests of our users to enhance the experience on our Online Properties. Third parties serve cookies through our Websites for advertising, analytics and other purposes. This is described in more detail below.
The specific types of first and third party cookies served through our Websites and the purposes they perform are described below (please note that the specific cookies served may vary depending on the specific Online Properties you visit)
### **How can I control cookies?**
You have the right to decide whether to accept or reject cookies. You can exercise your cookie rights by setting your preferences in the Cookie Consent Manager. The Cookie Consent Manager allows you to select which categories of cookies you accept or reject. Essential cookies cannot be rejected as they are strictly necessary to provide you with services.
The Cookie Consent Manager can be found in the notification banner and on our website. If you choose to reject cookies, you may still use our website though your access to some functionality and areas of our website may be restricted. You may also set or amend your web browser controls to accept or refuse cookies. As the means by which you can refuse cookies through your web browser controls vary from browser-to-browser, you should visit your browser's help menu for more information.
In addition, most advertising networks offer you a way to opt out of targeted advertising. If you would like to find out more information, please visit [http://www.aboutads.info/choices/](http://www.aboutads.info/choices/) or [http://www.youronlinechoices.com](http://www.youronlinechoices.com/).
The specific types of first and third party cookies served through our Websites and the purposes they perform are described in the table below (please note that the specific cookies served may vary depending on the specific Online Properties you visit):
### **Essential website cookies**
These cookies are strictly necessary to provide you with services available through our Websites and to use some of its features, such as access to secure areas.
### **Analytics and customization cookies**
These cookies collect information that is used either in aggregate form to help us understand how our Websites are being used or how effective our marketing campaigns are, or to help us customize our Websites for you.
| Name: | \_gat# |
| ----------- | ------------------------------------------------------------------------------------------------------------ |
| Purpose: | Enables Google Analytics regulate the rate of requesting. It is a HTTP cookie type that lasts for a session. |
| Provider: | .xano.com |
| Service: | Google Analytics [View Service Privacy Policy](https://policies.google.com/privacy) |
| Country: | United States |
| Type: | http\_cookie |
| Expires in: | 1 minute |
| Name: | \_gid |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Purpose: | Keeps an entry of unique ID which is then used to come up with statistical data on website usage by visitors. It is a HTTP cookie type and expires after a browsing session. |
| Provider: | .xano.com |
| Service: | Google Analytics [View Service Privacy Policy](https://policies.google.com/privacy) |
| Country: | United States |
| Type: | http\_cookie |
| Expires in: | 1 day |
| Name: | \_ga |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Purpose: | It records a particular ID used to come up with data about website usage by the user. It is a HTTP cookie that expires after 2 years. |
| Provider: | .xano.com |
| Service: | Google Analytics [View Service Privacy Policy](https://policies.google.com/privacy) |
| Country: | United States |
| Type: | http\_cookie |
| Expires in: | 2 years |
### **Advertising cookies**
These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.
| Name: | \_fbp |
| ----------- | ------------------------------------------------------------------------------------ |
| Purpose: | Facebook tracking pixel used to identify visitors for personalized advertising. |
| Provider: | .xano.com |
| Service: | Facebook [View Service Privacy Policy](https://www.facebook.com/privacy/explanation) |
| Country: | United States |
| Type: | http\_cookie |
| Expires in: | 90 days |
### **Unclassified cookies**
These are cookies that have not yet been categorized. We are in the process of classifying these cookies with the help of their providers.
| Name: | intercom-state-abk6h5qu |
| ----------- | ----------------------------------- |
| Purpose: | \_\_\_\_\_\_\_\_\_\_ |
| Provider: | [www.xano.com](http://www.xano.com) |
| Service: | \_\_\_\_\_\_\_\_\_\_ |
| Country: | United States |
| Type: | html\_local\_storage |
| Expires in: | persistent |
| Name: | intercom-session-abk6h5qu |
| ----------- | ------------------------- |
| Purpose: | \_\_\_\_\_\_\_\_\_\_ |
| Provider: | .xano.com |
| Service: | \_\_\_\_\_\_\_\_\_\_ |
| Country: | United States |
| Type: | http\_cookie |
| Expires in: | 7 days |
| Name: | intercom.played-notifications |
| ----------- | ----------------------------------- |
| Purpose: | \_\_\_\_\_\_\_\_\_\_ |
| Provider: | [www.xano.com](http://www.xano.com) |
| Service: | \_\_\_\_\_\_\_\_\_\_ |
| Country: | United States |
| Type: | html\_session\_storage |
| Expires in: | session |
| Name: | intercom-id-abk6h5qu |
| ----------- | -------------------- |
| Purpose: | \_\_\_\_\_\_\_\_\_\_ |
| Provider: | .xano.com |
| Service: | \_\_\_\_\_\_\_\_\_\_ |
| Country: | United States |
| Type: | http\_cookie |
| Expires in: | 9 months |
### **What about other tracking technologies, like web beacons?**
Cookies are not the only way to recognize or track visitors to a website. We may use other, similar technologies from time to time, like web beacons (sometimes called "tracking pixels" or "clear gifs"). These are tiny graphics files that contain a unique identifier that enable us to recognize when someone has visited our Websites or opened an e-mail including them. This allows us, for example, to monitor the traffic patterns of users from one page within a website to another, to deliver or communicate with cookies, to understand whether you have come to the website from an online advertisement displayed on a third-party website, to improve site performance, and to measure the success of e-mail marketing campaigns. In many instances, these technologies are reliant on cookies to function properly, and so declining cookies will impair their functioning.
### **Do you use Flash cookies or Local Shared Objects?**
Websites may also use so-called "Flash Cookies" (also known as Local Shared Objects or "LSOs") to, among other things, collect and store information about your use of our services, fraud prevention and for other site operations.
If you do not want Flash Cookies stored on your computer, you can adjust the settings of your Flash player to block Flash Cookies storage using the tools contained in the [Website Storage Settings Panel](http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html). You can also control Flash Cookies by going to the [Global Storage Settings Panel](http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html) and following the instructions (which may include instructions that explain, for example, how to delete existing Flash Cookies (referred to "information" on the Macromedia site), how to prevent Flash LSOs from being placed on your computer without your being asked, and (for Flash Player 8 and later) how to block Flash Cookies that are not being delivered by the operator of the page you are on at the time).
Please note that setting the Flash Player to restrict or limit acceptance of Flash Cookies may reduce or impede the functionality of some Flash applications, including, potentially, Flash applications used in connection with our services or online content.
### **Do you serve targeted advertising?**
Third parties may serve cookies on your computer or mobile device to serve advertising through our Websites. These companies may use information about your visits to this and other websites in order to provide relevant advertisements about goods and services that you may be interested in. They may also employ technology that is used to measure the effectiveness of advertisements. This can be accomplished by them using cookies or web beacons to collect information about your visits to this and other sites in order to provide relevant advertisements about goods and services of potential interest to you. The information collected through this process does not enable us or them to identify your name, contact details or other details that directly identify you unless you choose to provide these.
### **How often will you update this Cookie Policy?**
We may update this Cookie Policy from time to time in order to reflect, for example, changes to the cookies we use or for other operational, legal or regulatory reasons. Please therefore re-visit this Cookie Policy regularly to stay informed about our use of cookies and related technologies.
The date at the top of this Cookie Policy indicates when it was last updated.
### **Browser Cookie Controls**
In addition, your browser or device may offer settings that allow you to choose whether browser cookies are set and to delete them. These controls vary by browser, and manufacturers may change both the settings they make available and how they work at any time. As of 5 October 2020, you may find additional information about the controls offered by popular browsers at the links below. Certain parts of **Xano** may not work properly if you have disabled browser cookie use. Please be aware these controls are distinct from the controls that Xano offers you.
· [Google Chrome](https://support.google.com/chrome/answer/95647)\
· [Internet Explorer](https://support.microsoft.com/en-ie/help/17442/windows-internet-explorer-delete-manage-cookies)\
· [Firefox](https://support.mozilla.org/en-US/kb/cookies-information-websites-store-on-your-computer)\
· [Safari](https://support.apple.com/guide/safari/manage-cookies-and-website-data-sfri11471/mac)\
· [Safari Mobile](https://support.apple.com/en-us/HT201265)\
· [Opera](https://blogs.opera.com/news/2015/08/how-to-manage-cookies-in-opera/)
The date at the top of this Cookie Policy indicates when it was last updated.
### **Where can I get further information?**
If you have any questions about our use of cookies or other technologies, please email us at [support@xano.com](mailto:support@xano.com) or by post to:\
\
Xano, Inc.\
21600 Oxnard Street, Suite 910\
Woodland Hills, California 91367\
United States
Phone: [+1 (818) 275-4870](tel:8182937431)\
[support@xano.com](mailto:support@xano.com)
# DMCA Policy
Source: https://docs.xano.com/legal/dmca-policy
This Digital Millennium Copyright Act policy ("Policy") applies to the [xano.com](https://www.xano.com/) website ("Website" or "Service") and any of its related products and services (collectively, "Services") and outlines how this Website operator ("Operator", "we", "us" or "our") addresses copyright infringement notifications and how you ("you" or "your") may submit a copyright infringement complaint.\
\
Protection of intellectual property is of utmost importance to us and we ask our users and their authorized agents to do the same. It is our policy to expeditiously respond to clear notifications of alleged copyright infringement that comply with the United States Digital Millennium Copyright Act ("DMCA") of 1998, the text of which can be found at the U.S. Copyright Office [website](https://www.copyright.gov/).
### **What to consider before submitting a copyright complaint**
Please note that if you are unsure whether the material you are reporting is in fact infringing, you may wish to contact an attorney before filing a notification with us. We may, at our discretion or as required by law, share a copy of your notification or counter-notification with the account holder engaged in the allegedly infringing activity or for publication. If you are concerned about your information being forwarded, you may wish to [hire an agent](https://www.copyrighted.com/professional-takedowns) to report infringing material for you.
### **Notifications of infringement**
Please note that if you are unsure whether the material you are reporting is in fact infringing, you may wish to contact an attorney before filing a notification with us.
We may, at our discretion or as required by law, share a copy of your notification or counter-notification with the account holder engaged in the allegedly infringing activity or for publication. If you are concerned about your information being forwarded, you may wish to [hire an agent](https://www.copyrighted.com/professional-takedowns) to report infringing material for you.
If you are a copyright owner or an agent thereof, and you believe that any material available on our Services infringes your copyrights, then you may submit a written copyright infringement notification ("Notification") using the contact details below pursuant to the DMCA. All such Notifications must comply with the DMCA requirements. You may refer to a [DMCA takedown notice generator](https://www.websitepolicies.com/create/dmca-takedown-notice) or other similar services to avoid making mistake and ensure compliance of your Notification.
Filing a DMCA complaint is the start of a pre-defined legal process. Your complaint will be reviewed for accuracy, validity, and completeness. If your complaint has satisfied these requirements, our response may include the removal or restriction of access to allegedly infringing material as well as a permanent termination of repeat infringers’ accounts.
If we remove or restrict access to materials or terminate an account in response to a Notification of alleged infringement, we will make a good faith effort to contact the affected user with information concerning the removal or restriction of access, which may include a full copy of your Notification (including your name, address, phone, and email address), along with instructions for filing a counter-notification.
Notwithstanding anything to the contrary contained in any portion of this Policy, the Operator reserves the right to take no action upon receipt of a DMCA copyright infringement notification if it fails to comply with all the requirements of the DMCA for such notifications.
### Counter-notifications
A user who receives a copyright infringement Notification may make a counter-Notification pursuant to sections 512(g)(2) and (3) of the US Copyright Act. If you receive a copyright infringement Notification, it means that the material described in the Notification has been removed from our Services or access to the material has been restricted. Please take the time to read through the Notification, which includes information on the Notification we received. To file a counter-notification with us, you must provide a written communication compliant with the DMCA requirements.
Please note that if you are not sure whether certain material infringes the copyrights of others or that the material or activity was removed or restricted by mistake or misidentification, you may wish to contact an attorney before filing a counter-notification.
Notwithstanding anything to the contrary contained in any portion of this Policy, the Operator reserves the right to take no action upon receipt of a counter-notification. If we receive a counter-notification that complies with the terms of 17 U.S.C. § 512(g), we may forward it to the person who filed the original Notification.
The process described in this Policy does not limit our ability to pursue any other remedies we may have to address suspected infringement.
### Changes and amendments
We reserve the right to modify this Policy or its terms relating to the Website and Services at any time, effective upon posting of an updated version of this Policy on the Website. When we do, we will revise the updated date at the bottom of this page.
### Reporting copyright infringement
If you would like to notify us of the infringing material or activity, you may do so via the [contact form](https://www.xano.com/contact), send an email to [support@xano.com](mailto:support@xano.com) or write a letter to Xano, Inc. 21600 Oxnard Street, Suite 910 Woodland Hills, California 91367 United States.
This document was last updated on June 12, 2024
# General Disclaimer
Source: https://docs.xano.com/legal/general-disclaimer
### Website Disclaimer
The information provided by Xano, Inc. (“we,” “us” or “our”) on [https://www.xano.com](https://www.xano.com/) (the “Site”) is for general informational purposes only. All information on the Site is provided in good faith, however we make no representation or warranty of any kind, express or implied, regarding the accuracy, adequacy, validity, reliability, availability or completeness of any information on the Site. UNDER NO CIRCUMSTANCE SHALL WE HAVE ANY LIABILITY TO YOU FOR ANY LOSS OR DAMAGE OF ANY KIND INCURRED AS A RESULT OF THE USE OF THE SITE OR RELIANCE ON ANY INFORMATION PROVIDED ON THE SITE. YOUR USE OF THE SITE AND YOUR RELIANCE ON ANY INFORMATION ON THE SITE IS SOLELY AT YOUR OWN RISK.
### External Links Disclaimer
The Site may contain (or you may be sent through the Site) links to other websites or content belonging to or originating from third parties or links to websites and features in banners or other advertising. Such external links are not investigated, monitored, or checked for accuracy, adequacy, validity, reliability, availability or completeness by us. WE DO NOT WARRANT, ENDORSE, GUARANTEE, OR ASSUME RESPONSIBILITY FOR THE ACCURACY OR RELIABILITY OF ANY INFORMATION OFFERED BY THIRD-PARTY WEBSITES LINKED THROUGH THE SITE OR ANY WEBSITE OR FEATURE LINKED IN ANY BANNER OR OTHER ADVERTISING. WE WILL NOT BE A PARTY TO OR IN ANY WAY BE RESPONSIBLE FOR MONITORING ANY TRANSACTION BETWEEN YOU AND THIRD-PARTY PROVIDERS OF PRODUCTS OR SERVICES.
### Affiliates Disclaimer
The Site may contain links to affiliate websites, and we receive an affiliate commission for any purchases made by you on the affiliate website using such links.
### Testimonials Disclaimer
The Site may contain testimonials by users of our products and/or services. These testimonials reflect the real-life experiences and opinions of such users. However, the experiences are personal to those particular users, and may not necessarily be representative of all users of our products and/or services. We do not claim, and you should not assume, that all users will have the same experiences. YOUR INDIVIDUAL RESULTS MAY VARY.
The testimonials on the Site are submitted in various forms such as text, audio and/or video, and are reviewed by us before being posted. They appear on the Site verbatim as given by the users, except for the correction of grammar or typing errors. Some testimonials may have been shortened for the sake of brevity where the full testimonial contained extraneous information not relevant to the general public.
The views and opinions contained in the testimonials belong solely to the individual user and do not reflect our views and opinions. We are not affiliated with users who provide testimonials, and users are not paid or otherwise compensated for their testimonials.
# Privacy Notice
Source: https://docs.xano.com/legal/privacy-notice
This Privacy Notice describes the information collection, use, retention, and sharing practices of Xano, Inc. and its affiliates and subsidiaries (“Xano”, “we”, “us”, “our”) when you interact with us online through our website, [www.xano.com](http://www.xano.com) and its subdomains (e.g., security.xano.com) (collectively, the “Website”) or when you purchase our backend software or API (collectively, “Services”).
### OUR ROLE IN DATA PROCESSING
The entity responsible for the collection and use (processing) of your personal information when you use the Website or enquire about or engage or Services is Xano, Inc., which, for purposes of General Data Protection Regulation (“GDPR”) and the UK Data Protection Act 2018 (“DPA”), is the Data Controller. You can contact Xano by emailing us at [privacy@xano.com](mailto:privacy@xano.com) or by mail at 21600 Oxnard Street, Suite 910 Woodland Hills, CA 91367.
The entity responsible for the processing of your personal information when you use our backend software of APIs is Xano, Inc., which for purposes of General Data Protection Regulation (“GDPR”) and the UK Data Protection Act 2018 (“DPA”), is the Data Processor.
This Privacy Notice does not apply to the extent we process personal information in the role of a processor or service provider on behalf of our customers, including but not limited to where our customers create their own websites and applications running on our backend software.
### PERSONAL INFORMATION WE COLLECT, HOW WE USE IT, AND HOW WE SHARE IT
We collect personal information, which is information that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, to you, when you engage with the Website. As used in this Privacy Notice, “personal information” includes “Personal Data”, as defined under the GDPR and DPA. We will retain your information for as long as necessary for the purpose of the processing as more specifically set forth in this Privacy Notice unless we receive a request to delete this information and no exception to your right to deletion applies.
When you interact with our customer’s websites built using our Services, to the extent the General Data Protection Regulation (“GDPR”), Regulation (EU) 2016/679, and the UK Data Protection Act 2018 (“DPA”) apply to our customer, our role in connection with the data that we process to provide such services is that of a processor. To exercise your rights under the GDPR and/or the DPA, please file a request with the applicable customer and we will assist them in fulfilling your request.
When we collect or process your personal information on behalf of our customer, we are acting as a Service Provider under the California Privacy Rights Act (“CPRA”) and a Processor under EU/UK data protection laws or other US state comprehensive privacy laws (as applicable). We process and retain your personal information in accordance with the data processing agreement in place with our customer and applicable law.
Where Xano processes your personal information in the capacity of a data processor/service provider, and you seek to submit a privacy rights request, we will provide your request to our customer (or the ultimate data controller), or you can contact them directly and we will cooperate with the customer to facilitate your request.
\
**If you are interacting with us on behalf of your organization, this includes when you:**
* **Sign up for our solutions**. When you sign up for any of our solutions, we collect, from you, your personal identifiers (name, email address, phone number, and any other information you choose to provide) and your professional or employment-related information (company name). We use this information to create and manage your account. To the extent the EU or UK data protection laws apply, the legal basis for this collection is the performance of a contract. We share this information with our customer relationship management platform provider, lead enrichment provider, and event outreach provider to help manage the client relationship. To the extent the EU or UK data protection laws apply, the legal basis for the sharing with the event outreach provider is your consent. To the extent the EU or UK data protection laws apply, the legal basis for the remaining processing is our legitimate interest in providing the Services and maintaining the relationship more efficiently. In the event you are asked to sign documents in relation to your engagement of the Services, we will share this information with our e-signature provider. To the extent the EU or UK data protection laws apply, the legal basis for this processing is our legitimate interest in efficiently obtaining a legally binding execution of our agreement. This information may also be used for internal business analytics to assess Xano’s performance. To the extent the EU or UK data protection laws apply, the legal basis for this processing is our legitimate interest in improving the Services.
* **Make a payment**. When you make a payment, we collect, from you or from our third-party payment processor, your personal identifiers (name and email address), and your professional or employment-related information (organization name). We use this information to complete the transaction. We share your information with our third-party payment processor. To the extent the EU or UK data protection laws apply, the legal basis for this collection is the performance of a contract.
* **Conduct a video or voice call to discuss our services**. When we conduct a video call with you, we will collect your personal identifiers (name and business email address), visual and auditory information (sound of your voice and appearance through the video), and anything else you discuss or write in the chat during the video call. We will use this information to communicate with you. The legal basis for this processing is the performance of a future contract with you. This information will be shared with our video conference provider to provide the video conference services. To the extent the EU or UK data protection laws apply, the legal basis for this processing is the legitimate interest in providing an efficient and effective videoconference experience. With your consent, we may use our meeting assistance and note-taking software to help us take notes during the video call and share them with the participants. To the extent the EU or UK data protection laws apply, the legal basis for this processing is the legitimate interest in providing an efficient and effective videoconference experience. When we conduct a voice call, we will collect your personal identifiers (name and business telephone number) and anything else you discuss during the call. We will use this information to conduct the call. To the extent the EU or UK data protection laws apply, the legal basis for this processing is the performance of a future contract with you. This information will be shared with our telephone provider to provide the telephone communication services. To the extent the EU or UK data protection laws apply, the legal basis for this processing is the legitimate interest in providing an efficient and effective calling experience.
* **Request technical support**. When you submit a ticket for technical support, we will collect your personal identifiers (name, business email address, business telephone number), and employment information (company name, position). We use this information to process the ticket and troubleshoot the issue. To the extent the EU or UK data protection laws apply, the legal basis for this processing is the performance of a contract. We share this information with our support ticket management and chat provider, as well as our project and task management provider to process the request, keep track of the request, resolve the request, and keep a history of the tickets your company has submitted. To the extent the EU or UK data protection laws apply, the legal basis for this processing is the legitimate interest in providing an efficient and effective technical support and troubleshooting experience.
* **Communicate regarding our Services**. When you communicate with us via e-mail or Slack channel, we will collect your personal identifiers (name and email address) and your professional or employment-related information (company name), and any information you include in your communication with us. We will use this information to communicate with you about our current or potential Services. To the extent the EU or UK data protection laws apply, the legal basis for this processing is the performance of a contract. We will share this information with our communication provider. To the extent the EU or UK data protection laws apply, the legal basis for this is the legitimate interest in providing efficient communication with our clients.
**If you are a Website visitor, this includes when you**:
* **Contact us**. When you contact us through the Website, we collect, from you, your personal identifiers (name), your professional or employment-related information (work email address), and any additional information you choose to include in your message. To the extent the EU or UK data protection laws apply, the legal basis for this processing is that it is necessary for the performance of the service requested by you.
* **Interact with the website Virtual Assistant (“Chatbot”)**. With your consent, we collect any identifier (name), and any other information that you share with our Chatbot in the course of communicating with us through the chatbot. We share the content of your communications with our chatbot service provider to facilitate the use of the chatbot on the Website. To the extent the EU or UK data protection laws apply, the legal basis for this processing is consent.
* **Interact with us on social media**. When you interact with our social media pages on social networking websites, such as Bettermode, X (formerly known as Twitter) and LinkedIn (each a “Social Media Page”, collectively “Social Media Pages”), we collect basic engagement metrics and use it to tailor content and marketing and use it to improve user experience as set forth in this section. Please note that we do not control the use or storage of the information that you have posted to any social networking websites. This information is collected and processed by the social networking websites for their own purposes, including marketing. For more information on how Bettermode, X, or LinkedIn uses your personal information, please see, Bettermode’s [Privacy Policy](https://bettermode.com/legal/privacy-policy?), X’s [Privacy Policy](https://x.com/en/privacy) and LinkedIn’s [Privacy Policy](https://www.linkedin.com/legal/privacy-policy).
* **Social Media Pages**. When interacting with us on our Social Media Pages, we collect, from you, your personal identifiers (first and last name) and visual information (photograph (i.e., profile picture)), as well as any information that you provide when interacting with our Social Media Pages (e.g., commenting, sharing, and rating). We use this information to advertise our products, for events and invitations, and to communicate with users via the contribution and comment function. To the extent the EU or UK data protection laws apply, the legal basis for the processing is our legitimate interest in advertising our products via our Social Media Page and communicating with users, customers, and interested parties. Because our Social Media Pages are publicly accessible, when you use them to interact with other users, for example by posting, leaving comments or liking or sharing posts, any personal information that you post in them or provide when registering can be viewed by others or used by them as they see fit. The content posted on our Social Media Pages or other public areas of social networking websites can be deleted in the same way as other content that you have created. If at any time you want content posted to be deleted, please email your request to us at [privacy@xano.com](mailto:privacy@xano.com). Our Social Media Page incorporates a third party artificial intelligence chatbot search feature. To the extent the EU or UK data protection laws apply, the legal basis for the processing is our legitimate interest in providing efficient and effective search capabilities.
* **Community Management**. With the help of a third party we collect, from you, your interactions, including "likes", shares, messages and other interactions with the content, in order to analyze and evaluate how our content is perceived, to learn from it, and to improve our public relations efforts. To the extent the EU and UK data protection laws apply, the legal basis for analyzing your content is our legitimate interest in organizing, facilitating, and optimizing communication with our users and the general public.
* **Interact with the Website**. In addition to the personal information you provide directly to us, we also collect information from you automatically as you interact with our Website, including via cookies, pixels, web beacons, and similar tracking technologies. This includes, but is not limited to, the following internet or other electronic network activity information described below.
* If you visit our Trust Center (security.xano.com), we will collect your internet or other electronic network activity information (IP address, device identification information) to allow you to access the site. To the extent the EU and UK data protection laws apply, the legal basis for the processing is necessary to fulfill a contract with you. We cannot provide the Trust Center if you do not provide this information.
* We use essential, performance, marketing, and analytics cookies to collect your usage, device, and location information when you interact with the Website. We use this information to: (i) track you within the Website; (ii) enhance user experience; (iii) conduct analytics to improve the Website; (iv) prevent fraudulent use of the Website; (v) diagnosis and repair Website errors, and, in cases of abuse, track and mitigate the abuse; and (vi) provide targeted advertising. To the extent the EU or UK data protection laws apply, the legal basis for the placement and access of strictly necessary cookies is the performance of a contract. Particular third-party cookies to note on our Website include the following:
* **Google Analytics**. We use Google Analytics to collect information on your use of the Website for its improvement. To collect this information, Google Analytics installs cookies on your browser or reads cookies that are already there. Google Analytics also receives information about you from applications you have downloaded that partner with Google. We do not combine the information collected through the use of Google Analytics with personal information. Google’s ability to use and share information collected by Google Analytics about your visits to our Website or to another application which partners with Google is restricted by the Google Analytics [Terms of Use](https://marketingplatform.google.com/about/analytics/terms/us) and [Privacy Policy](https://support.google.com/analytics/answer/7318509?hl=en). To prevent your data from being used by Google Analytics, you can download the Google Analytics opt-out browser add-on, which can be accessed [here](https://tools.google.com/dlpage/gaoptout).
* **Amplitude**. We use Amplitude Session Replay to collect and analyze information about how you interact with and navigate the Services. To protect your privacy, we configure Amplitude to fully anonymize or mask all personal or account data displayed within your Xano account during a session replay, including all user-input fields and any sensitive on-screen information. Although the replay content is anonymized, the session itself is tied to a pseudonymous user ID, which allows us to link a session back to a specific account for support and diagnostic purposes. Amplitude may also collect anonymized metadata such as scroll behavior, click behavior, navigation flow, browser type, country, device type/ID, operating system, and session error logs. As part of this functionality, Amplitude may set or read first-party cookies or use other browser storage mechanisms. For more information about how Amplitude collects and protects your information, please visit Amplitude's documentation and [Privacy Notice](https://amplitude.com/privacy).
* **Aggregate and anonymize data**. We aggregate and anonymize the data we collect for benchmarking purposes and for internal analytics. We maintain and use this data in de-identified form. We will not attempt to re-identify the data, unless it is necessary to determine whether our deidentification processes satisfy applicable data protection laws.
\
Xano will also use the personal information we collect as described in this section to comply with the law, to efficiently maintain our business, and for other limited circumstances as described in **HOW WE SHARE YOUR PERSONAL INFORMATION**.
### DATA RETENTION
Unless otherwise stated in this Privacy Notice, we retain your personal information until we no longer need your information to fulfill the purposes for which we collected it or until we receive a valid request to delete the information, subject to certain exceptions. We may need to use and retain your personal information for longer than the periods indicated above for purposes of:
* **Compliance with our legal obligations**. For example, retaining your records for the purpose of accounting, dispute resolution, and compliance with labor, tax, and financial regulations.
* **Meeting our safety and security commitments**. Such as keeping our properties secure and preventing fraud.
* **Exercising or defending legal claims**. We also may need to retain personal information for longer than the periods indicated above in order to respond to legal process or enforceable governmental requests, or to enforce our contracts, including investigation of potential violations.
### HOW WE SHARE YOUR PERSONAL INFORMATION
Xano shares personal information as described in the **PERSONAL INFORMATION WE COLLECT, HOW WE USE IT, AND HOW WE SHARE IT** section, and generally in the following instances:
* **Within Xano**. We share your personal information within Xano for the legitimate business purposes of efficiently and effectively providing the Services. Access to your personal information is limited to those on a need-to-know basis. To the extent EU/UK data protection law applies, the legal basis for this is our legitimate interest in providing the Services more efficiently.
* **With service providers**. We share personal information with service providers that assist us in providing the Services. These service providers are described more specifically in the **PERSONAL INFORMATION WE COLLECT, HOW WE USE IT, AND HOW WE SHARE IT** section of this Notice. Generally, we may share your personal information with third-party contractors, partners, vendors, and providers we use to perform functions on our behalf for business purposes, including hosting or enriching data, support ticket provider, customer relationship management, tech and security support, payment processing, communications, and advertising.
* **In the event of a corporate reorganization**. In the event that we enter into, or intend to enter into, a transaction that alters the structure of our business, such as a reorganization, merger, acquisition, sale, joint venture, assignment, consolidation, transfer, change of control, or other disposition of all or any portion of our business, assets or stock, we would share personal information with third parties, including the buyer or target (and their agents and advisors) for the purpose of facilitating and completing the transaction. We will also share personal information with third parties if we undergo bankruptcy or liquidation, in the course of such proceedings. To the extent EU/UK data protection law applies, the legal basis for this is our legitimate interest in carrying out our business operations or, if required by law, consent.
* **For legal purposes**. We share personal information where we are legally required to do so, such as in response to court orders, subpoenas, governmental/regulatory bodies, law enforcement or legal process, including for national security purposes. We may share your information with our legal advisors or auditors to establish, protect, or exercise our legal rights or as required to enforce our terms of use or other contracts or to defend against legal claims or demands. We also share this information with third parties as necessary to: detect, investigate, prevent, or take action against illegal activities, fraud, or situations involving potential threats to the rights, property, or personal safety of any person; to comply with the requirements of any applicable law; or to comply with our legal obligations. To the extent EU/UK data protection law applies, the legal basis for this is compliance with legal obligations or our legitimate interest in compliance with other laws that apply to us.
* **With your consent**. Apart from the reasons identified above, we may request your permission to share your personal information for a specific purpose. We will notify you and request consent before you provide the personal information or before the personal information you have already provided is shared for such purpose. You may revoke your consent at any time by emailing us at [privacy@xano.com](mailto:privacy@xano.com).
### YOUR INFORMATION CHOICES
You have the following choices with respect to your personal information:
* **Opt out of marketing communications**. You may opt out of receiving marketing emails from us by clicking the “unsubscribe” link provided at the bottom of each email we send. Please note that we will continue to send you notifications necessary to the Services.
* **Opt out of email tracking**. You can disable this tracking by blocking automatic loading of images in your email.
* **Correct or view your information**. You may send an email to [privacy@xano.com](mailto:privacy@xano.com) to correct or view certain personal information of yours in our possession.
* **Delete your personal information**. You have the right to request the deletion of your personal information that we collect or maintain, subject to certain exceptions. For example, if we are required by law to retain the information that you are asking to be deleted, we would not be able to delete the information until we are legally permitted to delete it. To exercise your right to delete your personal information, you may send an email to [privacy@xano.com](mailto:support@xano.com).
* **Opt out of Google Analytics**. To prevent your data from being used by Google Analytics, you can download the Google Analytics opt-out browser, which can be accessed [here](https://tools.google.com/dlpage/gaoptout).
* **Opt out of interest-based advertising**. All session cookies are temporary and expire after you close your web browser. Persistent cookies can be removed by following your web browser’s directions. To find out how to see what cookies have been set on your computer or device, and how to reject and delete the cookies, please visit: [https://www.aboutcookies.org/](https://www.aboutcookies.org/). Please note that each web browser is different. To find information relating to your browser, visit the browser developer’s Website and mobile application. If you reset your web browser to refuse all cookies or to indicate when a cookie is being sent, some features of our website may not function properly. If you choose to opt out, we will place an "opt-out cookie" on your device. The "opt-out cookie" is browser specific and device specific and only lasts until cookies are cleared from your browser or device. The opt-out cookie will not work for essential cookies. If the cookie is removed or deleted, if you upgrade your browser or if you visit us from a different computer, you will need to return and update your preferences. By clicking on the “Opt-Out” links below, you will be directed to the respective third-party website where your computer will be scanned to determine who maintains cookies on you. At that time, you can either choose to opt out of all interest-based advertising or you can choose to opt out of targeted advertising by selecting individual companies who maintain a cookie on your machine. Please note that Xano adheres to the Digital Advertising Alliance’s self-regulatory principles.
* Network Advertising Initiative (NAI) Opt-Out: [https://www.networkadvertising.org/managing/opt\_out.asp](https://www.networkadvertising.org/managing/opt_out.asp)
* Digital Advertising Alliance (DAA) Opt-Out: [https://optout.aboutads.info](https://optout.aboutads.info)
* European Union (EU) /European Economic Area (EEA) Opt-Out: [http://www.youronlinechoices.eu](http://www.youronlinechoices.eu)
In general, to disable cookies and limit the collection and use of information through them, you can set your browser to refuse cookies or indicate when a cookie is being sent.
### DATA PRIVACY FRAMEWORK (DPF)
Xano complies with the EU-U.S. Data Privacy Framework (EU-U.S. DPF) and the UK Extension to the EU-U.S. DPF, as set forth by the U.S. Department of Commerce. Xano has certified to the U.S. Department of Commerce that it adheres to the EU-U.S. Data Privacy Framework Principles (EU-U.S. DPF Principles) with regard to the processing of personal data received from the European Union and the United Kingdom in reliance on the EU-U.S. DPF and the UK Extension to the EU-U.S. DPF. If there is any conflict between the terms in this privacy notice and the EU-U.S. DPF Principles, the Principles shall govern. To learn more about the Data Privacy Framework (DPF) Program, and to view our certification, please visit [https://www.dataprivacyframework.gov/](https://www.dataprivacyframework.gov/)
With respect to onward transfers of personal data received under the DPF, Xano remains liable for the processing of such transfers in accordance with these principles.
With respect to personal data received or processed pursuant to DPF, Xano is subject to the investigatory and enforcement powers of the U.S. Federal Trade Commission (“FTC”).
Pursuant to the EU-U.S. DPF and the UK Extension to the EU-U.S, EU & UK individuals have the right to obtain confirmation of whether we maintain personal information related to you in the United States. Upon request, we will provide you with access to the personal information that we hold about you. You may also correct, amend, or delete the personal information we hold about you. An individual who seeks access, or seeks to correct, amend, or delete inaccurate information transferred to the United States under EU-U.S. DPF, should direct their inquiry to [privacy@xano.com](mailto:privacy@xano.com).
We will provide an individual the ability to opt-out or opt-in choice before we share your data with third parties other than our agents, or before we use it for a purpose other than which it was originally collected or subsequently authorized. To request to limit the use and disclosure of your personal information, please submit a written request to [privacy@xano.com](mailto:privacy@xano.com).
If we become subject to an FTC or court order based on non-compliance, Xano will make public any relevant DPF-related sections of any compliance or assessment report submitted to the FTC, to the extent consistent with confidentiality requirements.
In compliance with the EU-U.S. DPF and the UK Extension to the EU-U.S. DPF, Xano commits to refer unresolved complaints concerning our handling of personal data received in reliance on the EU-U.S. DPF and the UK Extension to the EU-U.S. DPF to JAMS, an alternative dispute resolution provider based in the United States. If you do not receive timely acknowledgment of your DPF Principles-related complaint from us, or if we have not addressed your DPF Principles-related complaint to your satisfaction, please visit [https://www.jamsadr.com/DPF-Dispute-Resolution](https://www.jamsadr.com/DPF-Dispute-Resolution) for more information or to file a complaint. The services of JAMS are provided at no cost to you.
If your dispute cannot be resolved through the above channel, under certain conditions, you may invoke binding arbitration and residual claims not resolved by other redress mechanisms. You may do so by [clicking here](https://www.dataprivacyframework.gov/s/article/ANNEX-I-introduction-dpf).
### RIGHTS OF INDIVIDUALS IN THE EU AND UK
For any functions of the Service that we determine the purpose and means of the processing of your personal information, individuals in the EU and UK are entitled to certain rights under the General Data Protection Regulation (“GDPR”) and the Data Protection Act 2018 (“UK GDPR”). If our processing of your personal information is subject to the GDPR or UK GDPR, you may be entitled to the following rights:
* **Right to access**. When the legal basis for us to process your personal information is consent, performance of a contract, legal obligation, or legitimate interest, you have the right to ask us for copies of your personal information. This right has some exemptions, which means you may not always receive all the personal information we process.
* **Right to rectification**. When the legal basis for us to process your personal information is consent, performance of a contract, legal obligation, or legitimate interest, you have the right to ask us to rectify personal information you think is inaccurate or incomplete.
* **Right to erasure**. When the legal basis for us to process your personal information is consent, to performance of a contract, or legitimate interest, you have the right to ask us to erase your personal information in certain circumstances.
* **Right to restrict processing**. When the legal basis for us to process your personal information is consent, performance of a contract, legal obligation, or legitimate interest, you have the right to ask us to restrict the processing of your personal information in certain circumstances. This means you can limit the way that we use your personal information. You have the right to restrict processing when (1) you contest the accuracy of your personal information and we are verifying the accuracy of the personal information; (2) the personal information has been unlawfully processed and you oppose erasure and request certain restriction instead; (3) we no longer need the personal information but you need us to keep it in order to establish, exercise or defend a legal claim; or (4) you have objected to us processing your personal information under Article 21(1), and we are considering whether our legitimate grounds override yours.
* **Right to object to processing**. When the legal basis for us to process your personal information is legitimate interest, you have the right to object at any time, for reasons arising from your particular situation, to processing of your personal information, which is carried out on the basis of our legitimate interests. When the legal basis for us to process your personal information is your consent, you can withdraw your consent.
* **Right to data portability**. When the legal basis for us to process your personal information is your consent or performance of a contract, you have the right to ask that we transfer the personal information you gave us from one organization to another, or give it to you. Please note this only applies to personal information you have given us.
* **Right to lodge a complaint**. You have the right to lodge a complaint with the relevant Supervisory Authority. You can always submit a complaint directly to your local data protection authority (i.e., EU/EEA Member State data protection authority; UK Information Commissioner’s Office (ICO) or Gibraltar Regulatory Authority (GRA).
To exercise these rights, please contact us at [privacy@xano.com](mailto:privacy@xano.com).
### NOTICE FOR NEVADA RESIDENTS
Certain Nevada consumers may opt out of the sale of “personally identifiable information” for monetary consideration (as defined under Nevada law) to a person who in turn licenses or sells such information to another person. We don’t currently sell or provide your personal information in this manner. To opt out of the sale of your personal information in the future, you may submit a request to us via email to [privacy@xano.com](mailto:privacy@xano.com). Proof of identification may be required before such a request is granted.
#### DATA RETENTION
We retain your personal information (i) for as long as the relevant Xano account exists, (ii) until we no longer need your information to fulfill the purposes for which we collected it, or (iii) until we receive a valid request to delete the information, in which case we will delete or anonymize the information within 30 days after receiving the request. However, we may need to use and retain your personal information for longer than the periods indicated above for purposes of:
* **Compliance with our legal obligations**. For example, retaining your records for the purpose of accounting, dispute resolution, and compliance with labor, tax, and financial regulations.
* **Meeting our safety and security commitments**. Such as keeping our properties secure and preventing fraud.
* **Exercising or defending legal claims**. We also may need to retain personal information for longer than the periods indicated above in order to respond to legal process or enforceable governmental requests, or to enforce our contracts or Terms of Use, including investigation of potential violations.
### DO NOT TRACK
We do not respond to Do Not Track requests. Do Not Track is a preference you can set in your web browser to inform websites and mobile applications that you do not want to be tracked. You can enable or disable Do Not Track by visiting the Preferences or Settings page of your web browser.
### INFORMATION SECURITY
We implement appropriate technical and organizational security measures, such as access controls and encryption, to protect the personal information that we collect and maintain from unauthorized access, destruction, use, modification, or disclosure. Only authorized individuals are permitted to access personal information and they are required to treat this information as confidential. However, no security measure or modality of data transmission is 100% secure, and we are unable to guarantee the absolute security of the personal information we have collected from you. Our systems contain Controlled Unclassified Information (government-created or owned information that requires safeguarding or dissemination controls consistent with applicable laws, regulations, and government-wide policies) with specific requirements imposed by the Department of Defense. Our systems may be subject to other specified requirements associated with certain types of Controlled Unclassified Information such as Export Controlled Information.
### CHILDREN'S PRIVACY
The Services are not intended for individuals under the age of eighteen (18) years. If we learn that we have collected or received personal information from individuals under the age of eighteen (18), we will delete the personal information. If you believe we have personal information on individuals under the age of eighteen (18), please contact us at the contact information provided below.
### CHANGES TO THIS PRIVACY NOTICE
We may amend this Privacy Notice in our sole discretion at any time. If we do, we will post the changes to this page, and will indicate the date the changes go into effect. We encourage you to review our Privacy Notice to stay informed. If we make changes that materially affect Your Privacy Rights, we will notify you by prominent posting on the Website and/or via email, and obtain your consent, if required.
### CONTACT US
If you have any questions or concerns regarding this Privacy Notice, Please contact us by email at [privacy@xano.com](mailto:privacy@xano.com) or by mail at: \
\
21600 Oxnard Street, Suite 910\
Woodland Hills, CA 91367.
Last Updated: 06/26/2026
# Referral Agreement
Source: https://docs.xano.com/legal/referral-program/agreement
This agreement (“Agreement”) is entered between Xano. (“**Company**”), and Referral partner (“**Referrer**”), using the name and address submitted when completing the referral partner application. Whereas, Referrer has experience, business relationships, and network contacts within its industry, stands in a position to act as a Referrer with Xano; Whereas, Referrer will participate in Xano’s lead referral program in which Referrer will provide Xano with a potential customer identified by Referrer (“Leads”) in exchange for which Xano will pay certain commissions as described below. Whereas, Xano desires to engage the Referrer for the purposes of marketing and selling Xano’s Software and Services; and Therefore, in consideration of the following conditions set for the in this Agreement, the parties agree to the following.
#### Defined Terms
**Actively Participate**
Shall mean Referrer’s active engagement in the introduction of a Lead to Xano through an email; an in-person introduction; a telephone introduction; through a joint sales call; via the Xano shopping cart (most common method), or by using the referral form located at the Xano partner program website.
**Material Support**
Shall mean Referrer’s continued support of Xano through the sales process
**Commissionable Lead**
Shall mean a Lead for which Referrer is eligible under this Agreement to be paid a commission because the Lead has become a customer of Xano by executing a Xano Service Agreement for use of a Xano Service.
**Xano Lead Form or “RLF”**
Shall mean a standard form generated by Xano to be used by Referrer to identify a referred Lead for purposes of qualifying the Lead as a Commissionable Lead. Some leads will purchase via the Xano shopping cart.
**Lead Referral Date**
Shall mean the date Xano receives the RLF.
**Service**
Shall mean the on-line “Software as a Service” business application known as Xano or similar or successor product, which Xano licenses to Customers.
#### Relationship
Referrer is not an agent or legal representative of Xano for any purpose, and has no authority to act for, bind or commit Xano.
Referrer has no authority to make any commitment on behalf of Xano with respect to quantities, delivery, modifications, interfacing capability, suitability of software or suitability in specific applications. Referrer has no authority to modify the warranty offered with Xano products.
Referrer will not represent itself in any way that implies Referrer is an agent or branch of Xano. Referrer will immediately change or discontinue any representation or business practice found to be misleading or deceptive by Xano immediately upon notice from Xano.
Referrer must maintain an active paid Xano subscription in good standing in order to be eligible to receive any commission, referral fee, or other payment under this Agreement.
#### Term, Limitations, Termination
The term of this Agreement is twelve (12) months from the date of acceptance by Referrer and Xano. This Agreement shall automatically renew on each subsequent year for a one-year term, unless it is terminated earlier in accordance with this Agreement.
Xano or Referrer may terminate this Agreement without cause at any time upon thirty (30) days written notice or with cause at any time upon fifteen (15) days written notice, except that neither the expiration nor earlier termination of this Agreement shall release either party from any obligation which has accrued as of the date of termination.
Xano may, from time to time, give Referrer written notice of amendments to this Agreement. Any such amendment will automatically become a part of this Agreement thirty (30) days from the date of the notice, unless otherwise specified in the notice.
#### TERMS AND CONDITIONS OF LEAD REFERRAL AND ACCEPTANCE
Referrer’s Identification and Referral of Leads: Referrer acknowledges and agrees that in order for a Lead to qualify as a Commissionable Lead, the following must have occurred: Referrer must have provided valid details of the Commissionable Lead to a Xano and
Referrer must have timely documented the introduction of the Lead on a Xano Lead Form (“RLF”) and must have submitted the completed RLF to Xano for review; and
Xano must have reviewed Referrer’s RLF and accepted the Lead as commissionable (i.e., not rejected the Lead for any of the reasons stated in the Exclusions section below, or otherwise); or
Customer has completed an online order via the Xano shopping cart (using the Xano referral link that contains Referrer’s referral code).
Referrer acknowledges and agrees that no commission will be paid to Referrer by Xano for the referral of a Lead:
that was an existing customer of Xano’s at the time of the referral; or
with whom Xano was already involved in preliminary or advanced discussions relating toward the sale of a license to Lead (as of the date of the RLF); or
for whom a RLF (or similar document) has previously been submitted to Xano by Referrer or any other third party; or
Referrer acknowledges that it shall be solely responsible for and shall bear all costs associated with Referrer’s development of any Leads for referral to Xano.
**Xano’s Obligations Upon Lead Referral**
Xano hereby authorizes Referrer to refer Leads to Xano in exchange for the remuneration listed in Exhibit “A.”
Xano shall upon submission of a RLF from Referrer promptly review the RLF to determine whether to accept or reject the Lead as commissionable under the conditions of lead referral and acceptance section above, or other commercially reasonable reason as determined by Xano.
Xano will notify Referrer within 24-48 hours during business days (“Notification Date”) of receipt of the RLF as to whether the Lead submitted by Referrer to Xano is commissionable.
Upon acceptance of a Lead as commissionable, Xano shall be solely responsible for all costs associated with the sale of a License to said Lead.
**Mutual Obligations Re: Lead Development/Sale**
Each Party will cooperate with the other to develop and execute a strategy to best serve the needs of the Commissionable Lead, including how the Parties will work separately or together, if at all, regarding the Lead.
Each Party will, upon request of the other Party, provide the other with non-confidential information it has regarding a Lead in order to assist the other party in (i) verifying the eligibility of the Lead as commissionable; and/or (ii) successfully soliciting the Lead to purchase Xano products. This can be relayed via email, or by phone, but it is typically referred within the Online Referral Form found at the Xano partner program website. It does not apply if the referral completed an order within the Xano shopping cart.
Each Party will, upon request of the other Party, in its reasonable discretion, provide the other Party with information regarding its services and/or products. Such information shall include sales and marketing materials and informal training. Any training provided under this Section shall be conducted at mutually agreed times and places and shall be conducted in accordance with the training Party’s discretion.
Each Party will conduct all of its business in its own name and in a businesslike and professional manner. Referrer will not make any representations or guarantees concerning the Xano Services. Product guarantees are contained within the Xano end-user license agreement.
#### COMMISSIONS/REFERRAL FEES
Subject to the terms and conditions of this Agreement, and provided that Referrer maintains an active paid Xano subscription at the time the applicable commission is payable, Xano will pay Referrer a commission as determined by the schedule set forth in Exhibit “A” for each Commissionable Lead referred by Referrer to Xano in compliance with the requirements of this Agreement, that enters into a License Agreement with Xano. The payment of commissions will be made in U.S. Dollars. Referrer shall be solely responsible for payment of any and all national, state, and local taxes and charges arising from or imposed on the payments made to Referrer by Xano.
Payment Timing. Commissions under this Section shall be due no later than the last day of the “30-day period” following the “30-day period” after Xano actually receives the applicable payment of fees from the Commissionable Lead, but in no case earlier than the expiration of any return period agreed to by Xano and the Commissionable Lead.
This agreement is accepted when you click “submit” during the referral program application process.
**EXHIBIT A – PARTNER COMMISSION FORMULA**
For each Commissionable Lead, Xano will pay Referrer as specified below, of the Monthly Contract Value for Xano’s Software as a Service that is actually received and earned by Xano from the Commissionable Lead over the first year.
All actual amounts are redacted for confidentiality within this preview version of the agreement. Amounts can be obtained via phone or email from the partner manager, but will also be contained in the referral partner acceptance email.
**ENTERPRISE ACCOUNTS**
When it comes to Enterprise accounts, commission structures can vary widely depending on the specific scenario. Unlike standardized commission rates for retail, individual accounts, or agency accounts, Enterprise accounts often involve more complex negotiations and tailored solutions, which can result in custom commission structures to the referring party. Factors that may influence the commission rates for Enterprise accounts could include the size of the account, the length of the contract, the types of products or services being offered, and the level of support required. As a result, it's common for companies to work closely with their Enterprise clients to determine the most appropriate Xano setup structure that will align with both parties' interests and objectives.
***
*Last updated*: 06/08/2026
# FAQ
Source: https://docs.xano.com/legal/referral-program/faq
#### **How do I refer my friends to Xano?**
Just share your unique referral link, which you can find above. All your friends will need to do is click on that link, and they'll be guided through the sign-up process on the packages page.
#### **What is the referral link?**
The referral link is an easy way to share Xano with others. Rewarding your friends for trying Xano and you for making a successful referral.
#### **How much do I get paid by participating in the Xano Referral Program?**
* Xano current promotion pays a **10% referral** to you and **10% discount** incentive to your potential referral.
* Xano Agency plan holders receive a **20% referral** and **10% discount** incentive to any self-serve plans available via the billing portal. (**Note:** Enterprise plans do not include discounts. Also, if you downgrade or cancel and are no longer an agency plan holder, your active referral accounts will be switched to our standard 10% referral rate).
* Xano pays the referral % as long as the new customer is subscribed to a Xano **paid plan** with a maximum payout time frame of 12 months **(Note:** Agency plan holders do not have a 12 month limitation on payout timeframes).
#### **What is considered a successful referral?**
Standard Referral
A referral is successful when: 1. A user new to Xano signs up using your unique referral link, and... 2. Successfully pays a minimum of one month’s subscription. 3. Both referrer and referee are not the same entity or person.
#### **How will I know when I've successfully referred someone?**
You can track the status of your referrals from the Partner link directly from your Xano instance. From there you can go to **TRACKING STATS** on the dashboard or click on the **Stats** link on left side panel.
#### **My referral forgot to use my referral link. Is there a way to track it back to my account?**
We’re unable to track referrals back to your account if they did not use your referral link at the time they signed up.
#### **When and how will I get paid?**
1\. You will be eligible for payment once your referral has been a paid Xano customer with a maturity date of 30 days and a minimum payout of \$100. 2. Once you’re eligible for your first payment, you will receive an email asking for your PayPal information. 3. Between the 1st & 5th of any given month, following the referrals you made that are eligible for payments, you will receive a PayPal payment for any payments you earned.
**Note:** If you have a PayPal account and know your email address, then you already know how to receive money on PayPal. All you need to do is give us an email address and we are able to send you money through PayPal. You don't need an account for us to send you money, but you do need one to claim it.
#### **What is the difference between a user, subscription, and an invoice?**
* A **user** represents someone who signed up - regardless if they are paying or not.
* A **subscription** represents a paid package for an instance. If a user has 3 instances, then they would have 3 subscriptions. Subscriptions also show when the next billing cycle will start, which is important for you to see so you know when recurring revenue is coming in.
* An **invoice** is a record for each time a customer makes a payment on their subscription. Each invoice directly maps to commission for you.
#### **Some users have no subscriptions or invoices - what does that mean?**
If a user doesn’t have any subscriptions or invoices, it just means they are a free account. This information is still useful because free accounts have the potential to convert into paid subscriptions.
[ ](https://referral.xano.com/)
***
*Last updated*: 1/9/2025
# Subprocessors
Source: https://docs.xano.com/legal/xano-subprocessors
Current as of: March 20, 2026
Welcome to Xano's Subprocessor repository page where we maintain a current list of Subprocessors authorized to process customer data for Xano's services. Xano imposes data protection terms with Subprocessors regarding their security controls and applicable regulations for the protection of personal data.
The Data Subprocessors that Xano utilizes can be categorized into three categories:
### **Core Infrastructure Data Subprocessors**
These data Subprocessors apply to all self-serve and Managed Enterprise customers who utilize the Xano platform and are agnostic of product utilization.
### **Entities**
#### Google, LLC. - Google Cloud Platform (GCP)
* Entity Type: Cloud Service Provider / Infrastructure
* Service Location: USA & European Union
### **Support Data Subprocessors**
These Data Subprocessors may be utilized to support customers who may elect to share personal data with Xano support personnel.
### **Entities**
#### **Intercom R\&D Unlimited Company**
* Entity Type: Support Ticket Management & Chat
* Service Location: USA
#### **Segment.io, Inc.**
* Entity Type: Data Routing
* Service Location: USA
### Artificial Intelligence (AI) Subprocessors
Xano provides optional AI features and assistants powered and monitored for compliance by third-party platforms and model providers, which may be updated periodically.
### **Entities**
#### **Google LLC - Gemini AI**
* Model Families Utilized: Gemini Flash Lite, Gemini Flash, Gemini Pro
* Entity Type: Artificial Intelligence LLM
* Service Location: USA
#### **Braintrust Data, Inc.**
* Entity Type: AI Observability Service Provider
* Service Location: USA
# Pricing
Source: https://docs.xano.com/link/pricing
# Error Logs
Source: https://docs.xano.com/maintenance-monitoring-and-logging/error-logs
## Monitoring Errors Across your Workspace
Access the Error Logs dashboard from the left-hand navigation.
The dashboard provides a detailed overview of any errors that have occurred across your workspace over the last 24 hours.
### Header
At the top of the dashboard, you'll see a row of interactive cards detailing specific areas of errors present.
## Card Types
### All Errors
Displays all logged errors across your workspace. You can click individual time segments to drill into specific periods.
Each other card listed below displays:
* the total number of errors
* an error ratio ring comparing errors to successful runs
* when selected, a **clear** option to return to the default view
### Task
Displays errors occurring in background tasks.
### API
Displays errors occurring in your APIs.
### Function
Displays errors occurring in your custom functions.
### Middleware
Displays errors occurring in middleware execution.
### Trigger
Displays errors occurring in triggers.
## Error Table
Below the header is a table displaying more detailed information about each error logged across the workspace. You can filter the columns to drill down to specific statements, stacks, or time periods. Use the search box to quickly locate specific errors or workflows.
| Column | Description |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Past 24h | An interactive graph depicting the number of occurrences in the last 24 hours, or in the selected time period |
| Error | The standardized error code, and any custom message attached |
| Stack | Where the error occurred -- the same error across multiple workflows will each have their own row in the table, nothing is combined |
| Last Seen | When the error occurred most recently |
| First Seen | When the error first occurred |
| Urgency | A measure based on the ratio of errors to successful runs -- note that this does not indicate the true severity of the issue and is strictly based on volume |
## Accessing Error Logs for a Specific Workflow
Error Logs are available in the settings menu of most workflow types and provide quick access to:
* Review of any errors that occurred via external calls within the chosen timeframe (24 hours, 7 days, 30 days, or all available)
* How many times the error occurred
* The statement that triggered the error(s)
* The ability to ignore future occurrences of the error, or mark it as fixed
Click on the icon in the top right corner and choose
Use the options at the top to filter by time range or refresh if you're waiting for a specific error to appear, then select the error you'd like to explore further from the list below.
**Error code**
The standardized error message that identifies the error type.
**Error message**
Some errors, such as those triggered by preconditions, can have custom messages attached, which will appear here.
**Statement**
The statement that triggered the error.
**Occurrences**
The number of times the error occurred.
**First seen**
How long ago the first occurrence happened.
**Last seen**
How long since the most recent error of this type was logged.
**Error graph**
Shows a graph view of the errors per hour.
The error log also provides several actions you can take to manage errors:
**Ignore this error**
Marks the error as ignored, which will cause it to be hidden by default and not appear in the New error count.
**Mark as fixed**
Marks the error as fixed. Any reappearances of this error will be flagged as a regression.
**Captured Errors**
Provides quick access to specific requests from the request history that showcase the error. You can review variable state, inputs, and outputs from here.
Click the next to the Request Input to quickly copy the data sent and run it again using the debugger for further troubleshooting.
## What's next
Now that you're familiar with error logs, head to the Dashboard and review other errors that may be present in your request history. You may also find it helpful to use the [Statement Explorer](/maintenance-monitoring-and-logging/statement-explorer) to review other statements of the same type, even if they aren't experiencing errors currently, to proactively prevent similar issues from occurring.
# Instance Dashboard
Source: https://docs.xano.com/maintenance-monitoring-and-logging/instance-dashboard
Your instance dashboard can be accessed by opening the **Workspace Selector** in the top navigation bar and clicking **Back to Workspaces**.
The dashboard provides key metrics and information about what's happening in your Xano instance.
In addition to the dashboard, Xano automatically monitors your instance and sends **Instance Down** email alerts to instance admins when potential downtime is detected. These alerts include recommended steps such as performing a hard restart, adding database storage, or upgrading CPU capacity. See [What to Do If Your Instance Is Down](/troubleshooting-and-support/my-instance-is-down#instance-down-alerting) for more details.
# Memory Usage
Source: https://docs.xano.com/maintenance-monitoring-and-logging/instance-dashboard/memory-usage
In this screenshot, we can see a usage graph showing Database RAM is almost at 100%. **This is okay.** What we should be focusing on is the consistency. All this tells us is that the database is using as much RAM as it can to do the job it needs to be doing at a steady pace. Everything looks good!
Let's look at another example where we might have a problem.
In this screenshot, we can see that this instance's Lambda RAM isn't showing steady utilization -- there are significant peaks, valleys, and spikes. This tells us that there is sporadic intense load with Lambda functions we are using, and it will likely cause problems such as:
* Temporary system restarts and downtime
* Slow performance
* Failed requests
This is something that should be investigated further.
#### Reducing RAM Usage
If you are finding yourself in a situation where you are experiencing symptoms of RAM exhaustion, there are a few things you can to do try and mitigate the situation.CommentIt's important to note that in some cases, when mitigation is not possible, that may signal it's time to upgrade your Xano subscription tier to increase your available RAM. You can always reach out to Xano Support for further clarification.C
**Database RAM**
Spikes in Database RAM can be caused by one or more of the following:
* Tables that contain fields with large amounts of data, such as JSON payloads or sizable text content
* Try moving these large fields to a separate table or determining if you can reduce the amount of data stored.
* Depending on how often the data needs to be accessed, you can also store the large data in text files and store the file path in the table instead.
* Table references to other tables with a high number of fields
* Use the [Auto Complete](/the-database/database-basics/relationships#auto-complete) setting on the referenced table to reduce the amount of data loaded when viewing the table
* Running queries with joins on large tables
* Make sure you are using proper [indexing](/the-database/database-performance-and-maintenance/indexing) on large tables
* Use pagination on your base query
**API RAM**
Spikes in API RAM can be caused by one or more of the following:
* Function stacks that process large volumes of data
* Clear the contents of variables as they become unnecessary by updating them to blank values
* Move large data processing jobs to [background tasks](/the-function-stack/building-with-visual-development/background-tasks)
* Use post processing to execute any functions that aren't necessary to deliver a response
**Lambda RAM**
Please note that when using Lambda functions, the contents of **all variables** are loaded into Lambda memory. This is most often the cause of memory issues when using Lambda functions.
Spikes in Lambda RAM can be caused by one or more of the following:Comment
* Contents of other variables are too large for the Lambda to handle during processing
* Using file resources in conjunction with Lambdas
To mitigate issues with Lambda RAM, try using [expressions](/the-function-stack/data-types/expression) instead.
**Redis RAM**
Spikes in Redis RAM can be caused by one or more of the following:
* Heavy and/or inappropriate reliance on data caching functions
If you are not using data caching functions and still experiencing spikes in Redis RAM, please reach out to support.
**Tasks RAM**
Spikes in task RAM should be handled as you would handle spikes in API RAM.
# Performance Insights
Source: https://docs.xano.com/maintenance-monitoring-and-logging/performance-insights
Review performance of individual functions and function stacks throughout your workspace
## What can I see with Performance Insights?
Performance Insights enable you to analyze performance of specific function stacks or function types across your entire workspace. You'll be able to easily answer questions like:
* How long does a specific Lambda function take to run, on average, over the last 24 hours?
* What are my top 5 most resource intensive database queries?
* How many times did we run a bulk database operation over the last 30 days?
Performance Insights are the answer to every question you might have about how your backend in Xano is performing, and if it's not performing as expected, where to look to make improvements.
## How do I use Performance Insights?
From the sidebar, switch to the **Monitor** tab and select **Performance Insights**.
Use the image below and the table to learn more about each section of the Performance Insights screen.
| Key | What is it? | What's it for? |
| ----- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1** | | Choose a period of time to view data from |
| **2** | | Refresh available data |
| **3** | | Choose the type of statistics returned — Average: the average execution time of that function or function stack in the selected period of time; Count: the number of times the function or function stack was executed; Total Time: the total time of all executions of the function or function stack in the selected period of time |
| **4** | | Hover over any part of the chart to see specific statistics about that time period. |
| | | In some views, you'll be able to split the bar in the graph by function or function stack. |
| **5** | | Filter the graph and list of data to show either individual function calls, or function stacks. |
| **6** | | Filter the data by function types, or function stack types. |
| **7** | | In the list, you can click on the individual function or function stack to jump right to where it is in your workspace. |
Get quick visibility into the average length of time certain statements take to execute by viewing the logic in the Stack view.
# Request History
Source: https://docs.xano.com/maintenance-monitoring-and-logging/request-history
Request History records the requests that run through your workspace so you can inspect, debug, and monitor them after the fact. The revamped **Request History** dashboard brings every log type into a single workspace-level view with a 24‑hour activity graph, summary metrics, advanced filtering, and per‑request detail.
Request history is captured **per branch**. The dashboard shows the branch you currently have active — use **Switch branch** (or change your active branch) to view another branch's history.
## Ways to view request history
There are two ways to reach request history:
* **The Request History dashboard** — a workspace‑level page that brings every log type together with an activity graph, summary metrics, filters, and a searchable table. Most of this page covers the dashboard.
* **The slide‑out panel** — open request history for a single resource directly from its editor. See [Per‑object request history](#per-object-request-history).
This is a good opportunity to review your workspace settings by clicking the icon in the top-right corner. Specifically, take a look at:
* **Branch Defaults** - these determine what types of workflows are logged, and how much of each run is saved
* **Metrics Preferences** - both of these settings **must be enabled** to utilize all of the features of the request history dashboard, but are not required just to log requests
## The Dashboard
### Log types
| Tab | Records | Retention | Status/result | Free‑text search |
| -------------- | ------------------------------------------------------------------------------------------------------ | --------- | ---------------- | ----------------------- |
| **APIs** | Live API endpoint requests | 24 hours | HTTP status code | Search by URL/path |
| **Functions** | [Custom function](/the-function-stack/functions/custom-functions) runs that are part of a live request | 24 hours | Success / Error | Search by function name |
| **Tasks** | [Background task](/the-function-stack/building-with-visual-development/background-tasks) runs | 7 days | ok / exception | — |
| **Middleware** | Middleware runs | 24 hours | — | — |
| **Triggers** | Trigger runs (table, workspace, etc.) | 24 hours | — | Search by trigger name |
| **Tools** | AI/MCP tool runs | 24 hours | HTTP status code | Search by tool name |
What gets recorded differs by type:
* **Tasks** don't return a response, so no output/response is stored — but you still get the status, statement log, and timing.
* **Triggers** record their inputs (new/old record, action, data source) and timing; there is no output.
* **Middleware** records timing and the object it **wraps** (the API or task it ran for).
## The Dashboard
The dashboard inspects **one log type at a time**, selected from the tabs at the top of the page. You can also use the search, which supports a leading `!` to **exclude** matches — e.g. `!/api:auth/` hides requests whose path contains `/api:auth/`.
### Activity over the past 24 hours
The histogram at the top of the page shows **request volume over the past 24 hours** in hourly buckets.
* **Drag** across the histogram to select a time window; a small click clears the selection.
* Use the **from / to** time pickers, the **Quick select** presets, or the **previous / next** arrows to move the window.
* **Quick select** presets: *Any time, Past 5 minutes, Past 15 minutes, Past 1 hour, Past 4 hours, Past 24 hours*.
The histogram reflects the **Method** and **API group** filters (on the APIs tab) but not the other per‑request filters — those narrow the table only.
### Summary metrics
Below the histogram, a summary strip surfaces at‑a‑glance health for the current view:
* **Success rate** — percentage of successful requests, with an "X of Y requests" hint.
* **p95 duration** — 95th‑percentile response time ("95% of requests are faster").
* **Method mix** (APIs) — donut of GET / POST / PUT / PATCH / DELETE. Click a segment to filter by that method.
* **Status mix** (APIs & Tools) — donut of *Success 2xx / Redirect 3xx / User error 4xx / Server error 5xx*. Click to filter.
* **Result mix** (Functions & Tasks) — donut of *Success / Error* (Functions) or *ok / exception* (Tasks).
* **Latency distribution** — heatmap of request durations with a median (p50) marker.
These summary metrics are calculated from the requests **currently loaded** in the table, not a server‑side aggregate of all history. Click **load more** below the cards to retrieve a larger sample.
### Filtering and search
A compact filter bar sits above the table. Available filters depend on the active tab:
| Filter | Applies to | Notes |
| --------------- | -------------------------------- | ------------------------------------------------------------------------------ |
| **Search** | APIs, Functions, Triggers, Tools | Matches URL / name; prefix with `!` to exclude |
| **Time** | All | From/to pickers, quick‑select presets, or histogram drag |
| **Duration** | All | Min / max, in seconds |
| **Method** | APIs | GET, POST, PUT, PATCH, DELETE (multi‑select) |
| **Status** | APIs, Tools | Success 2xx, Redirect 3xx, User error 4xx, Server error 5xx |
| **Result** | Functions, Tasks | Success/Error (Functions); ok/exception (Tasks) |
| **API group** | APIs, Middleware | Multi‑select from your API groups |
| **User** | APIs, Functions, Tools | Filter by authenticated user (or *Unauthenticated*); typeahead by name/email |
| **IP** | APIs, Middleware | Add one or more IP addresses |
| **Frequency** | Tasks | Runs at least / at most every 5 min, 15 min, 30 min, 1 hour, 2 hours, 24 hours |
| **Action** | Triggers | Insert, Update, Delete, Truncate |
| **Table** | Triggers | Filter by the table the trigger fires on |
| **Data source** | Triggers | Filter by data source (when more than one exists) |
| **Per page** | All | 25, 50, 100, 500, 1000 (default 500) |
### The request table
Each tab shows a table sorted by **Time** (newest first) by default. **Time** and **Duration** columns are sortable. Columns vary by type:
* **APIs** — Time · Method · Status · Endpoint · Duration
* **Functions** — Time · Function · Called from · Runtime (Sync / Async) · Duration
* **Tasks** — Time · Task · Status · PID · Duration
* **Middleware** — Time · Middleware · Wraps · Duration
* **Triggers** — Time · Trigger · Action · Duration
* **Tools** — Time · Tool · Toolset · Status · Duration
Use **Load more** at the bottom to fetch the next page of results; the page shows **End of results** when there are no more.
## Inspecting a request
Click any row to open the detail panel for that request.
The panel includes:
* **Metadata** — time, user (if authenticated), IP, request/response size, status code, runtime mode, etc.
* **Input** — the request input/body (shows a note when the input exceeded the captured size limit).
* **Output / Response** — the response payload (omitted for Tasks and Triggers, which return no output).
* **Headers** — request/response headers, when captured.
* **Middleware stacks** — the PRE‑middleware, function stack, POST‑middleware, and post‑process steps. Stacks are limited by your branch's **statement limit** (see [Branch defaults](#branch-defaults)); a notice appears when the limit was reached or the stack wasn't recorded.
Action buttons in the panel:
* **Open in editor** — Click the route name at the top to jump to the editor
* **cURL** (APIs) — copy the request as a cURL command
* **Activate Debugger** — re‑run the request in the debugger (see below).
### Activate Debugger
From a request's detail panel, click **Activate Debugger** to re‑execute the request and open the [debugger](/testing-debugging/testing-and-debugging-function-stacks#using-the-debugger), where you can step through the entire execution one statement at a time. The request's original input is pre‑populated for you.
This is especially useful for investigating issues reported in production — you can replay the exact request that caused a problem and inspect each step of the function stack.
Activating the debugger **re‑executes the request against live data**. Depending on your logic, this could have side effects such as creating duplicate records, sending emails, processing payments, or modifying data. When you activate it on a **live branch** or a **production data source**, Xano warns you and asks you to confirm first. Use caution on requests that perform writes or trigger external services.
## Per‑object request history
You can also open the request history for a specific workflow directly from the editor.
This opens the a panel scoped to that object, showing its recent requests. Selecting a request shows the same [detail view](#inspecting-a-request) as the dashboard — inputs, output, headers, debug logs, function/middleware stacks, **cURL**, and **Activate Debugger**.
The panel also shows per‑object **stats** for that resource:
* A runs chart — *"Runs per \[interval], last \[24 hours / 7 days] (max 1,000 runs)"*. Tasks can toggle between **Last 24 Hours** and **Last 7 Days**.
* **Median duration**, plus **75% faster than** and **95% faster than** markers, with a latency heatmap.
## Exporting request history
On the detail panel, click the button to download the request history for that workflow as a CSV.
Click the export (download) action to open **Export Request History**, then choose:
* **Export using current request history filters** — limit the export to what your active filters match (on by default).
* **Include request output** — include full response payloads. This can take significantly longer depending on response sizes (off by default).
Exports are processed **in the background**. When the export is ready you'll receive an **email notification**, and the file is available to download for **12 hours**.
Export is only available for API request history at this time. You can export other types of request history through the [Metadata API](#accessing-request-history-via-API)
## Per‑type notes
A few behaviors are specific to certain log types:
* **Functions** show **Called from** (the API or function that invoked them) and a **Runtime** badge (Sync, Async (shared), Async (dedicated)). Async functions may show "—" for *Called from*.
* **Tasks** retain history for **7 days** and let you toggle the runs chart between **Last 7 Days** and **Last 24 Hours**. The **Frequency** filter finds tasks that run at least / at most every N minutes. Tasks have no response output.
* **Triggers** record the **Action** (insert/update/delete/truncate), the affected **Table**, and **Data source**. Like tasks, triggers return no output.
* **Middleware** shows what each run **Wraps** (the API or task it ran for).
* **Tools** show their parent **Toolset** and an HTTP **Status**.
## Managing request history
### Branch defaults
> These are the default settings for what is logged in your Request History.
In your workspace settings, the **Branch Defaults** panel controls whether request history is recorded for each resource type and how many statements are kept per request. Disabling history stops logging requests of that type; the statement limit caps how many function‑stack entries are stored per request.
You can set both values for each resource type that maintains history — **APIs (queries), functions, tasks, middleware, triggers, and tools**:
* **Default** — **Enabled** or **Disabled**.
* **Statement limit** — how many function‑stack statements to capture per request:
* No statements
* 10 statements
* 100 statements
* 1,000 statements
* 10,000 statements
* Store all statements
Request history uses your database (SSD) storage. The more statements you store per type — and the more types you log — the more storage request history consumes. Consider lowering the statement limit, or disabling history for high‑volume types, to keep storage in check.
#### Per‑object settings (inherit or override)
Each individual API, function, task, middleware, trigger, or tool can control its own request history from its settings panel. By default these are set to **Inherit Settings**, so they follow the branch defaults — or set them to **Enabled** / **Disabled** to override for that object specifically (tasks offer **Enabled** or **Inherit Settings**). When history is disabled for an object, its request‑history view shows a notice pointing you to the settings panel where you can re‑enable it.
## Clearing request history
From your **Instance settings** you can manually clear request history at any time. This can be useful to free up used disk space or to troubleshoot instances that are under extreme load and having trouble recovering. To access these options, head to your instance settings and select **Maintenance** under Request History.
### Database storage
This is the database table that holds your request history and counts against your instance's database storage. You can clear a portion or all of it. Use the **Force** option to halt running processes so the data can be cleared — note this may cause brief downtime while the server stops those processes.
**When should I use the 'force' option?**
This option is helpful if you are not just trying to clear the request history, but also trying to halt any currently ongoing writes to the database at the same time.
### Cache storage
Requests aren't written to the database immediately — they're held in a cache and flushed to the database at fast, regular intervals. During heavy traffic, clearing the request cache before items are flushed can help the instance recover. Items cleared from the cache are **not** written to the history database.
## Accessing request history via API
You can retrieve and search request history programmatically through the [Metadata API](/api-reference/request-history/search-function-request-history). Each log type has a "retrieve" (list) and a "search" (advanced filter + sort) endpoint, for example:
* `GET workspace/{workspace_id}/request_history` and `POST workspace/{workspace_id}/request_history/search`
* The same pattern for `function_history`, `task_history`, `middleware_history`, `trigger_history`, and `tool_history`.
Pass `include_output=true` to include full request/response payloads (this can produce large responses). These endpoints are also exposed as MCP tools (e.g. `getApiRequestHistory`, `searchApiRequestHistory`) for AI clients.
## Error logs
Failed requests with uncaught errors are also surfaced in [Error Logs](/maintenance-monitoring-and-logging/error-logs). Use Request History to inspect a specific request end‑to‑end, and Error Logs to triage failures across your workspace.
# Statement Explorer
Source: https://docs.xano.com/maintenance-monitoring-and-logging/statement-explorer
Use the Statement Explorer to quickly find instances of specific functions across all function stacks
## What is the Statement Explorer?
The Statement Explorer is used to find where certain functions are used across all of your function stacks.
This is useful for situations like:
* Trying to find all database queries to review efficiency
* Replacing all appearances of an existing function with improved logic
* Logic (code) reviews and security audits
## Using the Statement Explorer
You can search for statements or use the menu to find the ones you're looking for.
You can click **Restore last visited selection** to quickly return to your previous search.
# Navigating Xano
Source: https://docs.xano.com/navigating-xano
## Top Navigation Bar
1. **Workspace Selector** - Selecting this opens a comprehensive dropdown with workspace switching, billing and account information, referrals, theme settings, and a logout function
2. **Upgrade** - When applicable, we'll give you quick access to the most sensible upgrade path
3. **Connect** - Opens a modal offering several different options for connecting your backend to other entities, such as a frontend via REST APIs, MCP servers, or direct database connections
4. **Search Bar** - Search your entire workspace for any objects, such as tables or API endpoints. Can also be opened with Cmd / Crtl + K
5. **User/Team Menu** - Shows current workspace team members and gives quick access to team management and collaboration
6. **Drafts** - Provides quick access to all items currently in draft state, and an option to reset your drafts
7. **Publish** - Review any pending changes and publish them
8. **Workspace Settings** - Workspace settings, defaults, environment variables, GitHub Sync, middleware defaults, workspace triggers, processing jobs, realtime settings, database preferences, and Xano Link.
## Sidebar
The sidebar is separated into four categories. When the sidebar is expanded, all four tabs show as labeled buttons. When the sidebar is collapsed, only the active tab icon shows, with a dropdown to switch tabs.
* Dashboard
* Database
* Addons
* APIs
* Functions
* Agents & MCP
* Tasks
* Middleware
* Keys & Variables
* Tests
* Unit Tests
* Workflow Tests
* Tenant Center
* Performance Insights
* Audit Logs
* Compliance Center
* Static Hosts
* Public Files
* Private Files
## Footer
1. Branch Selector with color indicator and LIVE badge
2. Data Source selector with color indicator
3. Server Region
***
### Quick Reference: Where Did Everything Go?
| What | Old Location | New Location |
| -------------------- | ------------------------- | ------------------------------ |
| Workspace Selector | Top of sidebar | Top nav (left) |
| Branch Selector | Sidebar (below workspace) | Status footer (bottom) |
| Data Source Selector | Sidebar (below branch) | Status footer (bottom) |
| Search | Sidebar (top) | Top nav (center) |
| Settings | Sidebar menu item | Top nav (gear icon, right) |
| User/Profile Menu | Sidebar (bottom) | Top nav (right) |
| Help & Support | Sidebar (bottom dropdown) | Workspace selector dropdown |
| Marketplace | Sidebar menu item | Sidebar footer (icon dropdown) |
| Xano Agent | Under AI group | Top of Build tab (prominent) |
| Functions | Library group | Build tab |
| Middleware | Library group | Build tab |
| Tests | Library group | Test & Deploy tab |
| Tenant Center | Sidebar item | Test & Deploy tab |
| File Hosting | Library group | Host Files tab |
| Monitoring | Scattered/feature-flagged | Monitor tab |
# Quick Start Template
Source: https://docs.xano.com/quick-start-template
Spin up a working B2B SaaS backend in minutes with Xano’s Quick Start template.
The **Quick Start template** is a fully functional B2B SaaS backend that’s auto-created when you sign up for Xano.
Use it to run a live example instantly, then dive into each API group and function stack to **learn Xano by doing**.
It includes:
* A clean database model
* Grouped API endpoints
* Reusable custom functions
* A pre-configured AI Agent
* A lightweight HTML demo front end
Explore the demo, peek into the function stacks, and see exactly how it all fits together.\
You can expand the template for your use case — or simply use it as a **learning accelerator**.
***
## What's included?
### Authentication
Pre-built authentication flows, including password reset for when a user forgets their password.
### Members & Accounts
Users belong to accounts (organizations). **Roles** determine which endpoints they can access.
### Event Logging
A custom function records user actions to an `event_log` table for analytics and reporting.
### AI Agent
The `Xano_Example_Agent` uses a Tool connected to the Xano docs. Conversations and messages are stored for reference.
### Hosted Front-end Chatbot Demo
A lightweight HTML demo that showcases how a front end can interact with your Xano backend. It uses the APIs and data included in the template to build a simple chatbot that can answer questions about the Xano platform.
### Database
## A clean database model is included, with tables for users, accounts, logs, and agent messages.
## Demo
### Try the Chatbot
The demo (inside the **Authentication API group**) showcases how a front end communicates with your Xano backend. It includes signup, login, and password reset flows — plus a built-in **AI chatbot** powered by Google Gemini.
Open the demo by clicking API, choose the Authentication API group, and then click on the Launch Demo button.
You can ask the agent questions about Xano. It's linked to our documentation, so it can also serve as a general learning assistant as you learn how Xano works.
After signing up and using the chatbot, you'll see in the database records created for your user account, and the messages sent to and from the agent in the appropriate tables.
#### Password Reset (Optional)
1. **Request link:** `GET reset/request-reset-link` (ensure a user exists with the instance owner’s email)
2. **Magic login:** `POST reset/magic-login` → click the link in the email
3. **Update password:** `POST reset/update-password` → set a new password
The Send Email function allows up to 100 test emails to the **instance owner’s email** (the one you signed up with).\
To send more or use different recipients, add your **Resend API key** or connect a provider via Action or External API Request.
***
## Authentication & Password Reset
```http theme={null}
POST auth/signup
→ Create a user and return auth token
POST auth/login
→ Exchange credentials for auth token
GET auth/me
→ Return the current authenticated user
# Password reset flow
GET reset/request-reset-link → email link
→ POST reset/magic-login
→ POST reset/update-password
```
***
## AI Agent
The `Xano_Example_Agent` works **out of the box**, complete with complimentary tokens.\
It uses a single Tool to call an MCP Server and access Xano documentation — perfect for building your own prompt-based or tool-augmented workflows.
Check out the `demo-agent/conversation` function stack to see how the agent calls the Tool. Use it as a **blueprint** for your own agentic features.
***
## Event Logging
The template includes a **custom function** that logs events into the `event_log` table. It’s woven into many API endpoints, so you can track:
* Which features users engaged with
* What happened before a support ticket
* How usage varies by account or user
This is your launchpad for reporting, analytics, and monitoring.
***
## Members & Accounts
Common B2B app patterns are built in:
* Users can **create new accounts** (e.g., their team’s organization)
* Users can **join existing accounts**, **view teammates**, and **update their profile**
* **Role-based access control (RBAC)** is baked in:
* Admins can manage roles on their account
* Members have restricted access
* Admins can view all event logs; users can only see their own
RBAC is crucial for securing your app. Admin-only endpoints check user roles before proceeding.\
Use the built-in `role-based access control` function in your middleware for consistent enforcement.
***
## Database
| Table | Purpose |
| -------------------- | --------------------------------------------------- |
| `user` | App users (email, password hash, role, account\_id) |
| `account` | Organizations/teams; multiple users per account |
| `event_log` | Records of user actions for analytics |
| `agent_message` | Stores messages within conversations |
| `agent_conversation` | Parent threads for agent messages |
***
## APIs
The Quick Start template organizes endpoints into **API groups**:
### Authentication
Handles login, signup, password reset, welcome emails, and demo interactions.
* `GET 1_start_here_demo` — Launch the demo UI
* `POST auth/login` — Log in
* `GET auth/me` — Get authenticated user details
* `POST auth/signup` — Sign up
* `GET demo-agent/conversation` — Interact with the AI Agent
* `POST message/send_welcome_email` — Send a test welcome email
* `GET reset/request-reset-link` / `POST reset/magic-login` / `POST reset/update-password` — Password reset flow
`message/send-welcome-email` and `reset/request-reset-link` use the Xano Send Email function for **free testing emails** (up to 100).\
For production, add your own API key or external service.
***
### Event Logs
* `GET logs/admin/account_events` — Admins can pull logs for their entire account (with RBAC enforcement).
* `GET logs/user/my_events` — Users can view their own logs.
***
### Members & Accounts
* `POST account` — Create a new account
* `GET account/details` — Retrieve account info
* `GET account/my_team_members` — View team members
* `POST admin/user_role` — Admin updates user roles (RBAC enforced)
* `PATCH user/edit_profile` — Update user profile
* `POST user/join_account` — Join an existing account
***
## AI
### Xano Example Agent
A fully functional AI agent connected to a **Tool** that accesses Xano Docs via MCP Server. Complimentary tokens are included so you can start experimenting right away.
When ready, plug in your own provider keys to go beyond the example setup.
***
## Functions
Custom functions provide **reusable logic** for any API stack:
| Function | Purpose |
| --------------------------- | ---------------------------------------------------- |
| `Create_event_log` | Adds a record to the event logs table |
| `Generate_magic_link` | Helper for password reset flows |
| `Role-based access control` | Enforces permissions at the start of function stacks |
These functions can also be used as middleware when upgrading your workspace to enforce business rules consistently.
***
## Next Steps
The Quick Start template is a **launchpad**. You can:
* Expand and adapt it for production use
* Use it purely as a **learning sandbox**
* Or reset your workspace and build from scratch
The demo isn’t meant for production — it’s a guided example of how a front end can interact with a Xano backend.
# Channel Permissions
Source: https://docs.xano.com/realtime/channel-permissions
Channels are opened with your front-end's implementation of Realtime.
```javascript theme={null}
const marvelChannel = this.xanoClient.channel("marvel-chat-room");
```
Each channel needs to have permissions defined to ensure that they behave in the way that you expect and remain secure. On this page, we'll go over the various permission settings available and show you how to apply them.
Securing your Realtime channels is a multi-step process, and is not always solely reliant on the channel permissions you set. This includes:
* Setting the proper channel permissions for your use case
* Using nested channels to separate data
* Using [Realtime Triggers](/the-function-stack/building-with-visual-development/triggers) to act as a primary or secondary measure to block messages from being sent to the channel
* Generating separate authentication tokens for connecting to the realtime server
* Obfuscating the implementation on your front-end, and ensuring that channel creation is handled properly
## Permissions
### Anonymous Clients
Anonymous Clients means that you allow unauthenticated users to connect to your channels, but they can not send messages.
### Presence
Every client connected to this channel will receive a the list of all the other clients (including yourself). Note that authenticated client details will be augmented with the extra information stored in their JWT token.
### Client Public Messaging
This option allows authenticated and unauthenticated clients to send messages to the channel. These messages will be sent to all the users connected to the channel.
###
Similar to Client Public Messaging, this permission allows only authenticated users to send messages to the channel. Unauthenticated clients can still see the messages being sent to the channel.
### Client Authenticated Messaging
Every message sent to the channel by authenticated clients will only broadcasted to all other authenticated clients. This means that anyone can connect to that channel, but only authenticated client will receive messages broadcasted by the channel. Anonymous client will not receive any messages.
### Client Private Messaging
This enables clients to send messages directly to other clients without requiring authentication as long as both clients are present in the channel.
###
This permission enables client private messaging only between authenticated clients. Unauthenticated clients can not send private messages.
It's important to note that some of these permissions may appear to have logical dependencies, but they do not. For example, if you enable **Client Public Messaging**, this implies that \*\*Anonymous Clients \*\*is also enabled.
## Applying Permissions
From the Realtime Settings panel, click the icon shown below to define channel permissions.
On the next panel that opens, fill in the options shown.
#### Channel Status
Defines whether or not these channel permissions are utilized
#### Channel Target
This is essentially the name of the channel you are creating permissions for. Channel names can be dynamic to support creation of new channels from your front-end by enabling the **nested channels** option. Using nested channels along with a name like "chatroom/\*" will allow you to create channels that begin with "chatroom/" and anything else afterwards, such as a unique channel identifier. If you do not enable nested channels, the permissions will just apply to the channel name you specify.
#### Description
Give your permission layout a description for organizational purposes, if you wish.
#### Permissions
Using the list of permissions on this page, determine the correct set of permissions to apply to any channels that match the name pattern.
**Channel Triggers**
Triggers are function stacks that can run when messages or events are sent to the channel(s) impacted by these permissions. You need to first save your changes to enable adding triggers when creating new permissions.
For more information about Realtime Triggers, see [this section](/the-function-stack/building-with-visual-development/triggers) of our documentation.
## Permission Examples
Please note that **Presence** is usually optional no matter the scenario and is just based on if you want to utilize presence updates in your realtime channels.
| Context | Permissions |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
| A chat application where users can both connect and send messages anonymously | |
| A chat application where users can connect anonymously, but authentication is required to send messages | |
| A notification system that allows for unauthenticated users to connect so they can receive notifications, but sending messages is not allowed. You would send notifications to this type of channel through the Realtime Event function. | |
| A chat application that only allows authenticated users to connect and send messages | |
| A chat application that only allows authenticated users to connect, and allows direct client-client private messaging for authenticated users | |
# Realtime In Webflow
Source: https://docs.xano.com/realtime/realtime-in-webflow
**Realtime is in beta, and this documentation can change at any time.**
## Getting Started
* Make sure you've reviewed the Realtime documentation [here](/realtime/realtime-in-xano), as it is helpful to understand the process and how to use the Xano SDK before continuing.
* You need to be comfortable adding and modifying custom code in your Webflow project.
## Building a Live Chat in Webflow (Example)
Head to your Site Settings.
In the Custom Code section, paste the following line of code. This loads the Xano SDK and enables us to use it in the rest of our project. It also defines our 'xanoClient', which we'll call in our separate pages to enable Realtime functionality. Make sure to place your API group base URL and realtime canonical in the appropriate places, and click Save.
If you prefer, you can change the variable name `const ``xanoClient` to something else. Please note that any of our examples here will continue to use `xanoClient`, and you'll need to update them accordingly.
```html theme={null}
```
At this point, Webflow will ask you to publish your site to see the changes. Please note that you may need to view a published version of the site to verify that Realtime is enabled and working as expected.
Head back to the Designer, and we can start building realtime functionality into our project.
For this example, we've set up a simple chat application, similar to the example prepared in the main Realtime documentation.
We know that we want this page to connect to a specific channel, so let's head to our page settings and add some custom code.
```html theme={null}
```
Please note that when it comes to how you want to handle realtime implementation for your specific project, your custom code and configuration may look vastly different. The code provided in this section is for demonstration purposes only. Typically when performing an action like this in Webflow, it follows a basic structure, where we...
1. Create an element on our page to serve as a template, and assign it a class.
2. Once you have styled the element to your liking, give it a subclass. Change the properties of the subclass to set Display to None.
3. In your custom code, when it's time to render a message, you'll need to generate a copy of the original element containing the message or other content to show.
This piece of code, placed in the 'before \