In This Article

Exposing APIs

Wix offers two platform-managed mechanisms for exposing backend code at a public URL, HTTP functions and HTTP endpoints. With these, external systems can call into a Wix project to integrate with automation tools like Zapier or IFTTT, receive webhooks from external services, or share a backend with another application. Both are for backend-to-backend traffic. For a project's own frontend to call its backend, use a frontend-to-backend mechanism instead.

Which mechanism you use is determined by how your project is built:

HTTP functions: The mechanism for sites and Blocks apps. You add functions to the site's backend code, and each answers a URL derived from its name and HTTP verb.
HTTP endpoints: The mechanism for apps and headless projects built with the Wix CLI. You add route files, and each answers a URL derived from its location in the project's file tree.

Note: Self-managed apps and headless projects expose endpoints from their own backend stack instead.

About HTTP functions

HTTP functions expose public endpoints on sites and Blocks apps. Each function in the site's backend code answers a URL based on its name and HTTP verb, and runs on the same infrastructure as the site's other backend code, with access to the JavaScript SDK, data collections, and secrets.

Caller identity and security

A direct external call to an HTTP function is anonymous from Wix's perspective, so the function treats the caller as an anonymous site visitor. Methods that depend on a specific caller identity, such as the Get Current Member method, resolve to that anonymous visitor rather than a logged-in member. Anything sensitive the function exposes has to be guarded by authentication you implement yourself.

Note: HTTP functions are meant for server-to-server traffic. Don't use them to set cookies or otherwise act on a visitor's browser, which can put you out of step with data-privacy requirements.

Calls from another Wix project

When the caller is another Wix project, the platform offers a way around the anonymity. The HTTP Functions module wraps outbound calls with a Wix authentication layer, so the receiving function sees the caller's identity, and identity-dependent methods such as the Get Current Member method work as expected.

About HTTP endpoints

HTTP endpoints are the Wix CLI's file-based routing convention for exposing backend code from Wix-managed apps and headless projects. Each route file maps to a URL by its location in the project tree, and the endpoint runs on the same infrastructure as the project's other backend code, with access to the SDK, data collections, and secrets.

In the Wix CLI, HTTP endpoints replace the separate HTTP functions and web methods of the older CLI: a single endpoint serves both external callers and the project's own frontend. For the frontend side, see Frontend-to-Backend Communication.

Caller identity and security

A call that arrives without an authenticated token is anonymous from Wix's perspective, so the endpoint doesn't know who is calling it. An endpoint is reachable by anyone who knows its URL, so anything sensitive it exposes has to be guarded by authentication you implement yourself.

Exposing APIs across development paths

The development path determines how you expose endpoints:

Sites: Expose endpoints by adding HTTP functions to the site's backend code. The site must be published for production endpoints to be reachable. For implementation, see Write an HTTP Function in Extend Websites.
Wix-managed headless projects: Host backend code on Wix infrastructure and expose HTTP endpoints through the Wix CLI's file-based routing convention. For implementation, see Add HTTP Endpoints to Your Project in the Wix CLI portal.
Self-managed headless projects: Run their backends on infrastructure you manage, so exposing an endpoint is whatever your chosen stack supports. There's no Wix layer involved on the inbound path.
Wix-managed apps: Host backend code on Wix infrastructure and expose HTTP endpoints through the Wix CLI's file-based routing convention. For implementation, see Add HTTP Endpoints to Your Project in the Wix CLI portal.
Self-managed apps: Run their backends on infrastructure you manage, so exposing an endpoint is whatever your chosen stack supports. There's no Wix layer involved on the inbound path.
Blocks apps: Expose endpoints with the same HTTP functions model as sites, but their endpoints are namespaced per app so each installing site gets its own copy at a URL that identifies the app.