In This Article

Auth Scenarios

Each scenario below shows the identity, permissions, and authentication method behind a common Wix API call. Read them after Auth on the Wix Platform to see how the concepts combine in a real build.

For how to create the Wix client referenced in the SDK options below, see Set Up a Wix Client.

Add a product to a visitor's cart

You create a custom landing page on a site to promote a product on sale. When a visitor clicks Buy, your page's code calls the Cart API to add the product.

Identity: Visitor or member, set automatically by the site.
Permissions: Visitor-level access, including reading products and managing the visitor's own cart.
Authentication method: Host auth, applied automatically because the code runs on a Wix site.

Save feedback form submissions

You build a custom site page with a feedback form. When a visitor submits the form, the site's backend writes the entry to a CMS collection in a web method.

Identity: Visitor or member, inherited from the frontend caller.
Permissions: Visitor or member-level access, plus any data permissions configured on the collection.
Authentication method: Host auth, applied automatically on the site.

Confirm a booking automatically

You build automatic booking confirmation on a site. When a member books a slot, the site's backend calls Confirm Booking. Confirm Booking requires admin permissions the member doesn't have, so the backend elevates the call.

Identity: Visitor or member at the frontend. Elevated in the backend.
Permissions: Confirming a booking requires an admin role. Elevation provides the permissions the member doesn't have.
Authentication method: Host auth, applied automatically on the site.

Confirm a booking manually in the dashboard

You build a custom dashboard page where an admin can review pending bookings and confirm them. The page calls Confirm Booking.

Identity: Wix user. No elevation is needed.
Permissions: Confirming a booking requires an administrative bookings role. Whether the call succeeds depends on the Wix user's role.
Authentication method: Host auth, applied automatically because the code runs in the dashboard.

Generate an app orders report

You build an app with a dashboard page that displays a custom orders report. The page calls the Orders API directly.

Identity: Wix user.
Permissions: Depends on the Wix user's role. Admins or store managers can read orders.
Authentication method:
- Wix-managed: Host auth, applied automatically in the dashboard.
- Self-managed: OAuth, configured explicitly in your app's backend. With the JavaScript SDK, you create a client using dashboard.auth(). With REST, you can't authenticate as a Wix user in the dashboard. Instead, the page calls your app's backend, which calls the Orders API using an app token, so the call runs as the Wix app instead of the Wix user.

Run a headless store

You build a headless storefront that fetches products from a Wix store as an anonymous visitor.

Identity: Visitor. Established automatically by Wix's Astro integration in projects that use it; otherwise established through the OAuth visitor flow you set up.
Permissions: Visitor-level access to public products.
Authentication method: OAuth.
- With Wix's Astro integration: Handled automatically. The integration performs the OAuth token exchange for you.
- Without the Astro integration: Configured explicitly in your code, whether in a self-managed project or a Wix-managed project that brings its own frontend. With the SDK, you create a client using OAuthStrategy. With REST, you retrieve and manage OAuth visitor access tokens manually.

Log in a headless member

You build a self-managed headless storefront where visitors can sign in and manage their orders.

Identity: Member, established after your login flow completes.
Permissions: Member-level access, including reading the member's own orders and profile data.
Authentication method: OAuth (authorization_code), configured in your project's login flow. With the SDK, you create a client using OAuthStrategy with the member's tokens. With REST, you exchange the authorization code for member access and refresh tokens, then refresh before they expire.

Run a headless admin backend job

You build a nightly job in a self-managed headless project that syncs new products into the project's own Wix store.

Identity: Wix app. The headless OAuth client is an app installed on the site, and app tokens run as that app's identity with its granted scopes.
Permissions: Whatever scopes the OAuth client was granted in Headless Settings, for example "Manage products."
Authentication method: OAuth (client_credentials). Your backend exchanges the client ID and client secret for a short-lived admin access token at the start of each job run. There is no refresh token, so re-mint it when the token expires. With the SDK, you create a client using OAuthStrategy with the client secret. With REST, you call the token endpoint directly.

Sync data across account sites

You build a script that updates products on several sites in the same Wix account, or connects an external tool like a CI pipeline or AI agent to your Wix account.

Identity: API key admin.
Permissions: Configured on the API key when it was created, including which sites the key can access.
Authentication method: API key. The key is long-lived until revoked or rotated, so external tools and cross-site automation don't need OAuth token lifecycle logic. With the SDK, you create a client using ApiKeyStrategy. With REST, you send the key in the Authorization request header.