Content Upload
Upload Images, Videos, Audio, and Attachments
Xano allows for a wide range of files to be ingested and/or sent through your APIs and as a part of your Xano database. There are a variety of functions available for working with files in the No-Code API Builder.
How does content upload work?
The Content Upload Flow
When working with files in Xano, they can exist in a few different states.
File Resource
The file resource can be thought of as a reference to your raw file data. It is a base64 encoded string that represents the file during execution, enabling you to pass the data through variables and functions that handle content management with ease.
Raw File Data
When necessary, you do also have the ability to turn your file resource into raw file data, and manipulate it inside of the function stack when appropriate, such as a CSV file.
Metadata
While the metadata is not a representation of the file data itself, the metadata is necessary when the file needs to be referenced inside of a database table. The tables do not store the files themselves, but hold onto the metadata, so that when the record is retrieved, you can also retrieve the file data, or deliver a link to the file.
Files in Xano always start with a file resource. Here's what a typical flow looks like. In this example, we'll be adding a file to our database table.
Files in a function stack always start with a file resource. The file resource can come via a file resource input, or by using a Create File Resource function in the function stack itself (such as if the file comes from an external API request).
After we have our file resource (in this case, our File Resource input), we need to generate metadata for that file in preparation to store it in our database table.
Finally, once we have our metadata, we can write it to our database table, adding the metadata to the appropriate field in the record.
This is the simplest and most typical scenario when working with files in Xano. Following this flow will allow you to ingest files through your API and store them in your database. You can then read the metadata from the table and use the URL from there to deliver those files back to your front-end.
Input, Field Types, and Functions
The File Resource Input
Your content upload function stacks should always start with a file resource input, if your users are uploading files through your application. You can then utilize the file resource input in future functions, such as metadata generation, to store the file in your database or return a URL to the file.
Field Types
Xano supports several different field types in the database related to content upload.
Image - For storing images
Video - For storing video
Audio - For storing audio
Attachment - For storing anything else
Functions
The Content Upload Functions are:
Create Image Metadata - Creates image metadata from a file resource so that it can be formatted properly to be stored in Xano.
Create Video Metadata - Creates video metadata from a file resource so that it can be formatted properly to be stored in Xano.
Create Audio Metadata - Creates auto metadata from a file resource so that it can be formatted properly to be stored in Xano
Create Attachment Metadata - Creates attachment metadata from a file resource so that it can be formatted properly to be stored in Xano.
Create File Resource - This functions is able to create a file resource in the function stack from a variable. Typically, you will use a file resource as an input. However, there are certain use cases, for example, where you may hit an external API which is providing you with a raw image or file. In this event, you will want to first use this function to create a file resource then use one of the create metadata functions.
Zip: Create File Resource - Creates a new, empty zip file that you can add files to in your function stack
Zip: Add File Resource - Used to add additional files into an existing zip file
Zip: Remove File Resource - Used to remove files from an existing zip file
Zip: Extract Zip File Resource - Used to extract a zip file and generate separate file resources for each file extracted
Zip: View Contents - Show details about the files contained inside of a zip file
Click here for more specific information on working with zip files in Xano
Inputting Content
It's important to understand how content upload works through the API in Xano. Watching the tutorial at the top of this page is encouraged.
**When uploading content (i.e. image, video, or attachment), the content must be inputted as an input type of file resource**
Notice the difference of what the inputs look like, for example with image metadata input versus file resource:
Xano accepts base64 encoded files, URLs, or files uploaded directly in the debugger.
Typically, front-end tools will produce an image URL which you can use to upload the image to Xano through the file resource input type. This is common but each front-end is different so be sure to reference their documentation.
Function: Create File Resource This function can create a file resource in the function stack from a variable. You will want to use this function if you are working with an external API that is returning an image and you want to be able to store it in the Xano database. You still must create the image metadata like you would if you were using an input of file resource to upload an image. Note: While the File Resource input will accept base64 encoded imaegs, the Create File Resource function will not accept a base64 encoded image; this will have to be a decoded image.
Public vs Private Files
Xano supports two separate files libraries -- public and private files.
Public Files are files that have an always-accessible public link. This means that if a file is uploaded to your public files library, and a user retains access to that URL or saves it, they will always have access to that file until it is deleted. This is usually fine for non-sensitive data like product images, logos, etc...
Private Files are files that require a signed URL with a timed expiry attached. This means that even if someone gains access to the private URL for that file, they will no longer be able to access it once the time you specify has expired. Read more about working with private storage here.
Example - Upload an Image
Xano has convenient, pre-built API endpoints that you can use or reference if you are doing content upload.
If you select 'Add API Endpoint' to create a new API Endpoint, you will see the 'Content Upload' option.
Then you will have the option to choose from image, video, or attachment upload.
The API Endpoint will be set up with a file resource input type and a Create Image From File function.
The function, Create Image From File will create the image metadata from the value of the file resource input as shown below.
The file resource input can handle:
URL of the content.
Base64 encoded file.
The file itself
Upload using the file picker
Upload an Image URL or base64 Encoded File:
Below we have the same API endpoint set up: The input type is a file resource and the function is creating the metadata.
In this example, we are inputting the image URL directly into the Debugger. Since the debugger uses a file picker by default, we must manually write the input into the Debugger.
The result will show the image metadata for the inputted image:
Example using File Uploader through Swagger
Click on Documentation and to try out the API in Swagger.
Find the API.
Click on "try it out".
Upload an image.
Click "execute".
After uploading an image, this is the Metadata response from the "create image" API.
Adding an Image to the Database
There is an additional step needed to add the image to the Xano database. You must include an Add Record function after the Create Image Metadata function.
After inputting an image and running the API endpoint the result will be shown below.
Content Upload Limitations
Most file types are allowed, except for executable files.
File size limit is currently 64MB on the Build plan, 128MB on Launch, and 2GB on Scale.
What should / should not be stored as files in Xano?
It's important to note that files stored in your public files library will always be accessible via URL. This means that anyone with the URL will always be able to access that file until it is deleted from your files library (not just the database), regardless of whether or not they are authenticated.
We also support a separate private files library as a premium add-on or included with HIPAA compliance which you can utilize to provide authenticated file access via your function stacks. See this section of our documentation for more information.
Why is this different from data in my tables?
Access to data in your tables is directly determined by the Xano APIs you are building. This means that you can leverage things like authentication and separating data to ensure that there is no path to a user accessing data they should not. This differs from files stored in your public files library because of the lack of file-level access authentication.
What are some examples?
As an example, let's say you want to store some PII (personally identifiable information) about your users as part of their onboarding process, the user's social security number.
We can store the user's social security number in our database table, because we have employed proper methods to ensure that this data is not returned in any APIs, or only returned under specific circumstances to that individual user.
We should not store an image of the user's social security card in our public files library, because we are unable to, with 100% certainty, deny public access to this file. We can, however, leverage the private files library.
Last updated
