Wix CLI projects support HTTP endpoints, which you use to build backend APIs for handling HTTP requests and coordinating frontend and backend logic. HTTP endpoints can serve any kind of data.
Note: HTTP endpoints replace both HTTP functions and web methods from the legacy Wix CLI for Apps. See the migration guides for HTTP functions and web methods.
The location of an endpoint file in your project determines its URL. Place a file at src/pages/api/<name>.ts, and it's exposed at /api/<name>. For example, src/pages/api/users.ts becomes the route /api/users.
Endpoints are auto-discovered from the filesystem, so they aren't registered in src/extensions.ts and aren't generated by npm run generate.
Each endpoint file exports one or more HTTP method handlers, such as GET or POST. A handler receives the standard web Request and returns a standard Response, so you can return any content type, including JSON, plain text, images, and RSS feeds.
Handlers use the APIRoute type from astro, the underlying framework that powers HTTP endpoints.
Endpoints run on the server, not in the browser. This means you can:
Frontend extensions, like dashboard pages and site widgets, call endpoints using httpClient.fetchWithAuth() from @wix/essentials. This attaches the current user's access token to the request as an Authorization header, which the endpoint can then use to make elevated SDK calls for operations the user can't perform directly.
For the full pattern, see Add HTTP Endpoints to Your Project.
Unlike web methods, HTTP endpoints don't have a built-in permissions model. An endpoint is reachable by anyone who knows its URL, so enforcing access control is your responsibility.
To restrict access, inspect the caller's access token in your handler and decide whether to proceed:
httpClient.fetchWithAuth().@wix/essentials to read the token's subjectType, for example, to allow only site members or admins.Without fetchWithAuth() on the client, no token is sent and Get Token Info has nothing to inspect.
Use HTTP endpoints when you need to: