APIs
Learn more about building APIs using visual development in Xano
Last updated
Xano Documentation
Learn more about building APIs using visual development in Xano
Last updated
Quick Summary
Think of an API like a waiter in a restaurant - you (the user) give your order to the waiter (the API), who takes it to the kitchen and brings back exactly what you asked for. The waiter creates a seamless connection between you and the kitchen, just like an API connects different parts of an application.
An API acts like a messenger between different parts of an application. When your website needs something done (like creating a new user), it sends a request with the necessary data and gets back a response containing the results. Both requests and responses include headers (which provide context) and data (the actual content being sent or received).
When adding a new API endpoint in Xano, you have four options to choose from — some of which will give you prebuilt APIs, ready to go right away!
These are database operations for reading, adding, and updating data in your database.
These are APIs that handle login, signup, and checking an authenticated user's information.
These APIs facilitate file upload to Xano.
Start with a blank canvas. Build anything.
All APIs live inside of API groups. These are just like folders that you can use to organize all of your different APIs.
Each API group can be customized to your liking using the following options.
Name
The name of the API group. Each name in an API group must be unique, including trailing parameters. This means that if you have an API named /user/{user_id}, you can not also have an API named /user/getUser
Description
An internal description of the API group
Tags
Tags are used to label different things you build in Xano, used to search for related items across the workspace
Swagger
Determines the access level of your auto-generated API documentation Public - Anyone with the link can access Private (requires token) - Anyone with the link appended with an auto-generated token can access Disabled - No API documentation will be made available
Request History
Choose whether to inherit your workspace's default request history settings, or specify new ones for this API group
External Access
Quickly enable or disable public access to these APIs
Additionally, you can change the canonical ID of an API group from the Security section of the settings menu. The canonical ID dictates part of the endpoint URLs used to access those APIs, so proceed with caution before changing this.
Some of these settings are only available after the API group is created.
Choose from one of the four different API types available.
CRUD stands for create, read, update, and delete. These are basic database operations that most applications will need to perform on one or more tables.
Xano can create these for you automatically, based on your database tables.
Choose the table you want to create an action for.
Select the endpoint type you want to create.
Name
The name of the API endpoint. This also directly impacts the API URL.
Description
An internal description, just for you.
Verb
The API method
Tags
Use tags to organize objects throughout your Xano workspace and find them later
Request History
Inherit Settings
Use whatever is set in your workspace branch defaults
Other
Set specific request history settings for this endpoint
External access
When disabled, this endpoint will not respond to requests.
Authentication
Choose whether this endpoint requires a valid authentication token present in the headers to execute
Response type
Standard
Waits for execution to finish and delivers the response all at once
Streaming
Used with the Streaming API Response function, stream the response in chunks to a service that supports it
Response caching
Cache the response and redeliver it for future calls 📖 Learn more about response caching
To access your API groups, click in the left-hand navigation menu.
Click on a group to enter it, or click to create a new one.
Adjust any settings you wish for the new endpoint being created, and click
Adjust any settings you wish for the new endpoint being created, and click
Adjust any settings you wish for the new endpoint being created, and click
Adjust any settings you wish for the new endpoint being created, and click
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.
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.
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.
