In This Article

Identities

An identity tells Wix who or what's making an API call. You don't choose it directly. It comes from where your code runs and which authentication method was used. When that identity isn't authorized for a call, you may be able to elevate it to one with more permissions.

An API call can run as one of these identities:

Visitor: Someone browsing a site who isn't logged in.
Member: Someone browsing a site who's logged in.
Wix user: Site owners and collaborators acting in administrative contexts, such as dashboards and editors.
Wix app: An installed app calling APIs as itself, rather than as the visitor, member, or Wix user interacting with it.
API key admin: Administrative access represented by an API key.

Note: The same person can take on different identities depending on context. For example, a site collaborator can appear as a member when browsing the site and as a Wix user when working in the dashboard or editor.

Visitor

A visitor is someone browsing a site who isn't logged in.

The visitor identity is for actions like:

Reading public-facing content.
Managing visitor-level state like carts, which can persist across sessions in the same browser.
Starting login or sign-up flows.

Visitor identity has the narrowest access and can't call methods that require member, Wix user, app, or admin-level authorization.

Note: A visitor identity is session-bound. Wix-managed environments maintain that session for you, so state like cart contents survives across visits. In self-managed environments, you persist it across requests yourself by storing the visitor's tokens and reusing them. For details, see the authentication docs for your development path.

Member

A member is a visitor who has logged in. Unlike visitor IDs, a member's ID is persistent and doesn't change across sessions.

Members can do everything visitors can do, and can also perform member-specific actions, such as:

Reading or updating member-specific data, like their profile, orders, or bookings.
Accessing member-only pages and content.
Posting or submitting content as themselves, like comments and reviews.

When a site owner or collaborator logs into the site, the call still runs as the member identity, but that member session carries an extra Admin role on top of their member roles. That Admin role grants admin-level permissions, so they can call some methods that other members can't. This role is separate from the fine-grained roles the same person has as a Wix user in the dashboard or editor, and it authorizes only some administrative methods.

Note: Contacts and members are distinct entities.

A contact is created when someone shares their contact information with a site, such as by signing up or submitting a form. Contact IDs are used for CRM operations such as sending emails, not for access control.
A member is an authenticated identity. Each member links to a contact, but their IDs are different.

Wix user

A Wix user is a site owner or collaborator. Each Wix user has a user ID and can belong to multiple Wix accounts, for example as a collaborator on another Wix user's site. Sites, domains, and installed apps belong to an account, which has its own account ID.

A person takes on the Wix user identity only in administrative contexts like the dashboard and editor. The identity is role-sensitive: two Wix users making the same call can receive different authorization results depending on their roles. To learn more, see Roles & Permissions.

The Wix user identity is for actions like:

Managing site or business settings in the dashboard and editor.
Managing site resources such as products, media, or campaigns.

Note: When the same person is logged into the live site instead of working in the dashboard or editor, the call runs as a member with admin permissions, not as a Wix user. That member identity is authorized for only some administrative methods, so a call that succeeds for a Wix user in the dashboard can fail for the same person acting on the site.

Wix app

A Wix app is the identity a call gets when an app calls APIs as itself, rather than on behalf of the visitor, member, or Wix user interacting with it. This identity is tied to a specific installation on a specific site, called an app instance, created when the app is installed.

The same identity applies regardless of how the app is distributed:

A public app that any Wix user can install, whether listed in the Wix App Market or shared via install link.
A private app available only on your own sites or your organization's enterprise sites.
The OAuth client behind a headless project, which is itself a private app installed on the site.

The Wix app identity is permission-sensitive: two apps making the same call can receive different authorization results depending on which scopes each was granted at installation. When an app acts on behalf of a Wix user instead, the app's scopes combine with the Wix user's role. See Permissions.

The Wix app identity is for actions like:

Running backend logic as the installed app.
Reading or writing site data using the app's granted scopes.

Note: For a headless project, the identity depends on the token. A token minted with the client ID alone runs as a visitor or member, while exchanging the client ID and secret for an app token runs as the OAuth client's own app instance: the Wix app identity.

API key admin

API key admin is the identity used by calls authenticated with an API key.

The API key admin identity is permission-sensitive. Two API keys making the same call can receive different authorization results depending on the permissions assigned to each when it's created.

The API key admin identity is for account-level or site-level administrative operations that don't rely on active visitor, member, or Wix user session context, such as:

Inviting team members and managing their roles.
Managing site resources such as products, media, or campaigns in a headless project.

Identities across development paths

Which identities are available depends on your development path and where your code runs:

Sites: Visitor, member, or Wix user, depending on where the code runs.
Wix-managed headless projects: Visitor, member, Wix user, or Wix app, depending on where the code runs.
Self-managed headless projects: Visitor and member via OAuth, Wix app via the OAuth client's credentials, and API key admin via API keys.
Wix-managed apps: Visitor, member, Wix user, or Wix app, depending on where the code runs.
Self-managed apps: Visitor, member, Wix user, and Wix app, via OAuth.
Blocks apps: The same identities as Wix-managed apps.

For the same breakdown as a table, see Auth Quick Reference. For the identity behind common build scenarios, see Auth by scenario.

For the identity a specific extension type runs with, see the Authentication and permissions section of that extension's article in the Extensions Framework. For backend mechanisms such as web methods, HTTP functions, scheduled jobs, and backend events, see the Backend Services articles.