Frontend-to-Backend Communication

Frontend code runs in the browser, where anyone can read it. Backend code runs on a server, where secrets, third-party credentials, and sensitive logic can live safely. Most non-trivial projects need both sides to talk to each other.

When both your frontend and backend run on Wix infrastructure, the platform provides a managed mechanism for connecting them. Which one you use is determined by how your project is built:

• Web methods: The mechanism for sites and Blocks apps. You call a backend function from the frontend as if it were local, and Wix handles the transport and attaches the caller's identity.
• HTTP endpoints: The mechanism for apps and headless projects built with the Wix CLI. The frontend calls a backend route over HTTP, with the caller's token attached.

About web methods

A web method is a backend function wrapped with a platform-provided helper that makes it callable from the frontend code of the same site. On sites and in Blocks apps, web methods live in files with a .web.js extension, and each declares a permission level, such as anyone, site members only, or admins only. The platform serializes the call, enforces that permission level against the caller, runs the function, and returns the response.

Web methods aren't publicly exposed. A web method is reachable only from the frontend of the same site. The platform also attaches the caller's identity to the invocation, so platform methods that depend on caller identity, such as the Get Current Member method, work without any extra effort on your part.

About HTTP endpoints

An HTTP endpoint is a server-side route in a Wix-managed app or headless project that handles HTTP requests. The same route can be called both by the project's own frontend and by external systems, so identity isn't guaranteed: a call that arrives without a token is treated as anonymous.

When the project's own frontend calls the endpoint, the Wix CLI's authenticated fetch helper (httpClient.fetchWithAuth() from @wix/essentials) attaches the caller's access token to the request as an Authorization header. The endpoint reads that token to act on the caller's behalf, including making calls the caller couldn't make directly.

Frontend-to-backend communication across development paths

The development path determines which mechanism applies. Self-managed paths don't use either, so the transport is yours to choose.

• Sites: Declare web methods in the site's backend code, and the site's frontend code calls them by importing them like any other backend function. For implementation, see Call Backend Code from the Frontend in Extend Websites.
• Wix-managed headless projects: Use HTTP endpoints; web methods are a sites-and-Blocks mechanism. For implementation, see Add HTTP Endpoints to Your Project in the Wix CLI portal.
• Self-managed headless projects: Run their backend on infrastructure you manage, so web methods and Wix's identity attachment don't apply. You choose the transport between your frontend and your own backend, and you propagate the caller's identity yourself by forwarding visitor or member OAuth tokens. See About Authentication.
• Wix-managed apps: Use HTTP endpoints; web methods are a sites-and-Blocks mechanism. For implementation, see Add HTTP Endpoints to Your Project in the Wix CLI portal.
• Self-managed apps: Run their backend on infrastructure you manage, so web methods and Wix's identity attachment don't apply. You choose the transport between your frontend and your own backend, and you propagate the caller's identity yourself using a signed app instance object that your backend verifies with your app's secret key. See Authenticate Incoming Requests to Your Self-Hosted Backend.
• Blocks apps: Use the same web methods model as sites. Each installing site's frontend calls its own copy of the Blocks app's web methods.

See also

• For the related concept of exposing backend code to external callers rather than to your own frontend, see Exposing APIs in this section.