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?

Learn about the content upload flow, what's supported, and what isn't.

Input, Field Types and Functions

Get acquainted with the File Resource input, and each of the different file field types and functions

Inputting Content

Learn the nuances of ingesting files via your Xano APIs

Public vs Private Files

When should you use public files vs private files?

Content Upload Example

See an example function stack for uploading an image to Xano

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.

1. 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).

2. 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.

3. 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**

Use the input type file resource to upload images, videos, or attachments.

Notice the difference of what the inputs look like, for example with image metadata input versus file resource:

File resource is the correct input type to upload an image. Image (metadata) is incorrect.

Xano accepts base64 encoded files, URLs, or files uploaded directly in the debugger.

The file upload feature 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.

Add a new API Endpoint that is Content Upload.

Then you will have the option to choose from image, video, or attachment upload.

Choose the type of content you are uploading.

The API Endpoint will be set up with a file resource input type and a Create Image From File function.

The pre-built upload image API endpoint.

The function, Create Image From File will create the image metadata from the value of the file resource input as shown below.

Create the content metadata from the file resource input.

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:

A successful response with the newly created image metadata.

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".

Using Swagger to upload an image.

After uploading an image, this is the Metadata response from the "create image" API.

The response, in Swagger, of the newly created image metadata.

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.

Make sure to map the image field to the result of the Create Image from File return variable.

After inputting an image and running the API endpoint the result will be shown below.

A newly created record with an uploaded image through the API. Xano will output the image URL for convenience.

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.