The Data API gives Studio Two site code direct access to a site's data. Use it to add, update, remove, and query items, run aggregations, and manage collections and indexes.
The Data API is in the @wix/data package, which is preinstalled in every Studio Two site. Import the APIs you need. For example:
The Data API includes several APIs. The main ones are:
items: Work with the items in collections. Includes adding, updating, and removing items, bulk operations, queries with filters and sorting, and aggregations.collections: Create collections and manage their fields and permissions.indexes: Speed up queries by managing a collection's indexes.externalDatabaseConnections: Connect external databases to a site.The items API also includes data events, which run backend code after an item is created, updated, or deleted.
The API reference pages sometimes mention $w, data hooks, or a suppressHooks option. Studio Two has no $w API and no data hooks, so those don't apply.
For every API, see the CMS API reference.
You can call the Data API from:
items API is available as wixData, with no import. See Query Items.Note: The code examples in these articles use await. In site code, run them inside an async function.
The items API follows the role-based permissions of each collection. A collection's permissions decide who can read, add, update, and remove its items, such as anyone, site members, or only admins. A request fails if its caller doesn't have permission for the operation. A Wix Data view script runs with the permissions of the credentials that the view is connected with. With a CLI login, that's the logged-in Wix user. With an API key, it's the permissions that the key grants.
In backend code, you can run a method with elevated permissions using auth.elevate() from @wix/essentials. This overrides the collection's permissions for that call. For example:
Elevate only in backend code. Before you pass visitor input to an elevated method, validate it, because the elevated call ignores the collection's permissions.
Wix stores a site's data in a primary database and replicates it to mirror databases around the world, so queries are fast wherever they're made from. Mirror databases catch up with the primary database shortly after a change, but in the meantime a query might not include the change yet, if it's answered by a mirror database that hasn't received the update. This behavior is called eventual consistency.
When you need the latest data immediately after a change, pass { consistentRead: true } as the query's third argument. The query then reads from the primary database, which can be slower, and its results aren't cached. For example:
Learn more about eventual consistency.
Last updated: 2 November 2026