HTTP endpoints let you build backend APIs that handle HTTP requests, serve data to frontend extensions, and integrate with external services. Endpoint files run on the server and can return any content type, including JSON, plain text, images, and RSS feeds.
HTTP endpoints aren't traditional extensions. Unlike other backend extension types, they aren't registered in src/extensions.ts, aren't generated by npm run generate, and don't appear on the Extensions page in the app dashboard.
Note: HTTP endpoints replace HTTP functions and web methods from the legacy Wix CLI for Apps. If your project uses either, see the migration guides for HTTP functions and web methods.
The location of an endpoint file in your project determines its URL. A file at src/pages/api/<name>.ts is exposed at /api/<name>. For example, src/pages/api/orders.ts becomes /api/orders. Endpoints are auto-discovered from the filesystem — no registration step.
Each endpoint file exports one or more HTTP method handlers, such as GET or POST. A handler receives a standard web Request and returns a standard Response. Handlers use the APIRoute type from Astro, the framework that powers HTTP endpoints in the Wix CLI.
Endpoints run server-side, so they can read environment variables (including secrets), call external services without exposing credentials to the client, and use Wix APIs with elevated permissions.
Frontend extensions call endpoints using httpClient.fetchWithAuth() from @wix/essentials. This method attaches the current user's access token as an Authorization header. The endpoint can then use that token to make elevated SDK calls on behalf of the user.
HTTP endpoints don't have a built-in permissions model. Any caller who knows the URL can reach an endpoint. Access control is your responsibility: inspect the caller's token in the handler using getTokenInfo() from @wix/essentials and decide whether to proceed based on the caller's identity.
HTTP endpoints are available in Wix CLI projects:
Last updated: 2 August 2026