Velo: Exposing a Site API with HTTP Functions

Visit the Velo by Wix website to onboard and continue learning.

Using Velo you can create functions to expose the functionality of your site as a service. That means other people can use the functionality of your site by writing code that calls your site's API as defined by the Wix functions you create.

Important: The HTTP Functions API is only intended for use in server-to-server communications. If you use this API to set a cookie on a site visitor's browser you may no longer be in compliance with applicable data privacy regulations.

You might want to use HTTP functions to:

  • Integrate your site with an automation tool, such as Zapier or IFTTT.
  • Receive notifications and information from external webhooks. 
  • Share a backend between your site and a native mobile application.

Endpoints

Clients consume your HTTP functions by reaching endpoints using the following pattern:

  • For premium sites: https://www.{user\_domain}/\_functions/<functionName>.
  • For free sites: https://{user\_name}.wixsite.com/{site\_name}/\_functions/<functionName>.

You can test your HTTP functions by reaching endpoints using the following pattern:

  • For premium sites: https://www.{user\_domain}/\_functions-dev/<functionName>.
  • For free sites: https://{user\_name}.wixsite.com/{site\_name}/\_functions-dev/<functionName>.

Notes:

  • You can test your HTTP functions using Functional Testing. You do not have to publish your site before doing so.

  • When using Git Integration, you can test your code in the local editor or push your code to GitHub and run functional testing with the Wix code editor.

  • You must publish your site at least once before using either testing or production endpoints. After that, you can do the following:

    • To make changes made to testing endpoints take effect, save your site.
    • To make changes made to production endpoints take effect, publish your site.

Permissions

HTTP functions, no matter how they are invoked, always run with the permissions of an anonymous site visitor.

API Function Code

API function logic is defined in a file you create and name http-functions.js in your site's backend. 

HTTP functions are defined using the following pattern:

Copy
1

where prefix is one of get, post, put, delete, or use.

Inside an HTTP function, you can write the logic to handle an incoming request and return an appropriate response. The function receives a WixHttpFunctionRequest object that contains information about the incoming request. The function must return a WixHttpFunctionResponse. There are a number of functions you can use to create the WixHttpFunctionResponse, such as response(), ok(), created(), notFound(), serverError(), badRequest(), and forbidden().

See the API reference for Wix HTTP Functions for more information.

get( )

This function responds to requests made with the HTTP GET method. Usually, it is called by consumers to retrieve a resource and should have no other effect. If defined in this way and the resource is found, your function should respond with a 200 (OK) status code and the requested resource.

Example: Create a GET HTTP function that queries a collection to find items based on the path of the request.

Copy
1

post( )

This function responds to requests made with the HTTP POST method. Usually, it is called by consumers to create a new resource. If defined in this way and the resource is created, your function should respond with a 201 (Created) status code and usually a reference to the new resource.

Example: Create a POST HTTP function that inserts an item from the request's body into a collection.

Copy
1

put( )

This function responds to requests made with the HTTP PUT method. Usually, it is called by consumers to update an existing resource. If defined in this way and the resource is updated, your function should respond with a 200 (OK) status code. If defined in this way and the resource did is created because it did not exist, your function should respond with a 201 (Created) status code.

Example: Create a PUT HTTP function that updates an item from the request's body in a collection.

Copy
1

delete( )

This function responds to requests made with the HTTP DELETE method. Usually, it is called by consumers to delete an existing resource. If defined in this way and the resource is deleted, your function should respond with a 200 (OK) status code.

Example: Create a DELETE HTTP function that deletes an item from a collection based on the path of the request.

Copy
1

use( )

This function responds to requests made with any of the GET, POST, PUT, or DELETE  HTTP methods unless another function is defined specifically for the request's HTTP method.

For example, if you create functions named get_myFunction and use_myFunction, GET calls to myFunction will be handled by get_myFunction, while POST, PUT, and DELETE calls will be handled by use_myFunction.

Debugging

You can debug HTTP functions by adding console.log() calls to them.

The information you log appears in the function output when using Functional Testing and in your site's Logs.

The information logged by code that runs on the backend can also be viewed as Site Events. Site Events are accessible via Developer Tools > Logs on the site dashboard.

Was this helpful?
Yes
No