> Portal Navigation: > > - Append `.md` to any URL under `https://dev.wix.com/docs/` to get its markdown version. > - Pages are either content pages (article or reference text) or menu pages (a list of links to child pages). > - To get a menu page, truncate any URL to a parent path and append `.md` (e.g. `https://dev.wix.com/docs/sdk.md`, `https://dev.wix.com/docs/sdk/core-modules.md`). > - Top-level index of all portals: https://dev.wix.com/docs/llms.txt > - Full concatenated docs: https://dev.wix.com/docs/llms-full.txt ## Resource: Identities ## Article: Identities ## Article Link: https://dev.wix.com/docs/overview/auth-permissions/identities.md ## Article Content: # 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](https://dev.wix.com/docs/overview/auth-permissions/authentication-methods.md) was used. When that identity isn't authorized for a call, you may be able to [elevate](https://dev.wix.com/docs/overview/auth-permissions/elevation.md) it to one with more permissions. An API call can run as one of these identities: - [**Visitor**](#visitor): Someone browsing a site who isn't logged in. - [**Member**](#member): Someone browsing a site who's logged in. - [**Wix user**](#wix-user): Site owners and collaborators acting in administrative contexts, such as dashboards and editors. - [**Wix app**](#wix-app): An installed app calling APIs as itself, rather than as the visitor, member, or Wix user interacting with it. - [**API key admin**](#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](https://dev.wix.com/docs/overview/auth-permissions/permissions.md), 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](https://support.wix.com/en/article/roles-permissions-overview). 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](#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](https://dev.wix.com/docs/build-apps/develop-your-app/access/app-instances/about-app-instances.md), 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](https://dev.wix.com/docs/overview/auth-permissions/permissions.md) 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](https://dev.wix.com/docs/overview/auth-permissions/permissions.md). 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](https://dev.wix.com/docs/overview/auth-permissions/authentication-methods.md#api-keys). 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](https://dev.wix.com/docs/overview/auth-permissions/auth-quick-reference.md#by-development-path). For the identity behind common build scenarios, see [Auth by scenario](https://dev.wix.com/docs/overview/auth-permissions/auth-quick-reference.md#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](https://dev.wix.com/docs/overview/extensions-framework/about-extensions.md). For backend mechanisms such as web methods, HTTP functions, scheduled jobs, and backend events, see the [Backend Services](https://dev.wix.com/docs/overview/backend-services/backend-development-on-wix.md) articles. ## See also - [Authentication Methods](https://dev.wix.com/docs/overview/auth-permissions/authentication-methods.md) - [Permissions](https://dev.wix.com/docs/overview/auth-permissions/permissions.md) - [Auth Quick Reference](https://dev.wix.com/docs/overview/auth-permissions/auth-quick-reference.md)