Go Headless

Build Apps

Client

API Preview

test

Ricos

Develop Websites

REST

Velo

GraphQL (Alpha)

# About the Wix Stores Locations

The Wix Stores Locations API is Read Only and provides access to online stores inventory locations data.
To create or update the locations you should use the [Wix Locations API](fallback::https://dev.wix.com/docs/rest/business-management/locations/introduction).
Only inventory type locations will be shown in the WixStoresLocations API.
Each online stores inventory item is associated with a location. The location is a physical or virtual place where the item is stored. The location can be a warehouse, a store, or any other place where the item is kept.

When a store is created automatically a default online stores location is created. This location is used for all the items that don't have a specific location assigned.


## Major functionality
The WixStoresLocationService API exposes read only functionality for having wix stores locations data.
In order to create a new location that will be associated with your site you should call the [Wix Locations API](fallback::https://dev.wix.com/docs/rest/business-management/locations/introduction)
Create Location endpoint and after the creation you should update the location to be inventory type by calling Update Location endpoint.
After complete those steps you will see the new location in the WixStoresLocationService API.
Every update or delete action should be done in the [Wix Locations API](fallback::https://dev.wix.com/docs/rest/business-management/locations/introduction) and will be reflected to WixStoresLocations.

## Before you begin
It’s important to note the following points before starting to code:
* The site owner must have the Wix Stores app installed.
* Your app has the necessary permissions to access the WixStoresLocations API.

## Sample flows
* [Create a New Stores Location via the business management](fallback::https://dev.wix.com/docs/rest/business-solutions/stores/catalog-v3/stores-locations-v3/sample-use-cases-and-flows)
* [Update or Delete Stores Location](fallback::https://dev.wix.com/docs/rest/business-solutions/stores/catalog-v3/stores-locations-v3/sample-use-cases-and-flows)

## Terminology
- **StoresLocation**: business inventory location.
- **Virtual Location**: a location that is not a physical location like online stores without warehouse.
- **Default location**: online stores default location .
- **Wix Location**: wix site locations.


# Stores Locations: Sample Use Cases and Flows
This article shares some possible use cases your app could support, as well as a sample flow that could support each use case. This can be a helpful jumping-off point as you plan your app's implementation.

### Create a New Stores Location via the business management
You can also create a location via the business management, and then do call to update the new location type to inventory.
1. Go to the Business Management -> Settings -> Business Info and click on Add New Location.

### Update or Delete Stores Location
This can be done in the business management.
Go to the Business Management -> Settings -> Business Info and update or delete the location.


# Stores Locations: Supported Filters and Sorting

The following table shows field support for filters and sorting for the Stores location object:

| Field             | Supported Filters                                                      | Sortable |
|-------------------|------------------------------------------------------------------------|----------|
| `id`              | `$eq`, `$ne`, `$exists`, `$in`, `$hasSome`, `$startsWith`              |          |
| `createdDate`     | `$eq`, `$ne`, `$exists`, `$in`, `$hasSome`, `$lt`, `$le`, `$gt`, `$ge` | Sortable |
| `updatedDate`     | `$eq`, `$ne`, `$exists`, `$in`, `$hasSome`, `$lt`, `$le`, `$gt`, `$ge` | Sortable |
| `wixLocationId`   | `$eq`, `$ne`, `$exists`, `$in`, `$hasSome`, `$startsWith`              |          |
| `name`            | `$eq`, `$ne`, `$exists`, `$in`, `$hasSome`, `$startsWith`              | Sortable |
| `locationType`    | `$eq`, `$ne`, `$exists`, `$in`, `$hasSome`                             | Sortable |
| `defaultLocation` | `$eq`, `$ne`, `$exists`, `$in`, `$hasSome`                             | Sortable |


__Related content:__
[API Query Language](fallback::https://dev.wix.com/docs/rest/articles/getting-started/api-query-language),
[Query Stores Locations](fallback::https://dev.wix.com/docs/rest/business-solutions/stores/catalog-v3/stores-locations-v3/query-stores-locations)

localDc

tell us why you're invalidating the cache. You don't need to add your app name

reason

InvalidateCache

appDefId

instanceId

Invalidate by filename (for media files such as PDFs)

fileName

metaSiteId

File

pageId

Page

URI path to invalidate (e.g. page/my/path) - without leading/trailing slashes

uriPath

Invalidate by file (for media files such as PDFs)

Invalidate by msId. NOT recommended, as this will invalidate the entire site cache!

Invalidate by Site ID. NOT recommended, as this will invalidate the entire site cache!

siteId

getBy

identityType

IdentificationData

WebhookIdentityType

ID of a site visitor that has not logged in to the site.

anonymousVisitorId

appId

ID of a site visitor that has logged in to the site.

memberId

ID of a Wix user (site owner, contributor, etc.).

wixUserId

data

eventType

The identification type and identity data.

MessageEnvelope

value

BoolValue

Empty

paths

FieldMask

Int32Value

Int64Value

values

ListValue

NullValue

StringValue

fields

Struct

nanos

seconds

Timestamp

Value

boolValue

listValue

nullValue

numberValue

stringValue

structValue

kind

bodyAsJson

ActionEvent

A sequence number defining the order of updates to the underlying entity.
For example, given that some entity was updated at 16:00 and than again at 16:01,
it is guaranteed that the sequence number of the second update is strictly higher than the first.
As the consumer, you can use this value to ensure that you handle messages in the correct order.
To do so, you will need to persist this number on your end, and compare the sequence number from the
message against the one you have stored. Given that the stored number is higher, you should ignore the message.

entityEventSequence

Assumes actions are also always typed to an entity_type
Example: wix.stores.catalog.product, wix.bookings.session, wix.payments.transaction

entityFqdn

ID of the entity associated with the event.

entityId

Event timestamp in [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) format and UTC time. For example: 2020-04-26T13:57:50.699Z

eventTime

Unique event ID.
Allows clients to ignore duplicate webhooks.

If present, indicates the action that triggered the event.

originatedFrom

This is top level to ease client code dispatching of messages (switch on entity_fqdn+slug)
This is although the created/updated/deleted notion is duplication of the oneof types
Example: created/updated/deleted/started/completed/email_opened

slug

Whether the event was triggered as a result of a privacy regulation application
(for example, GDPR).

triggeredByAnonymizeRequest

DomainEvent

body

entityAsJson

Indicates the event was triggered by a restore-from-trashbin operation for a previously deleted entity

EntityCreatedEvent

deletedEntityAsJson

EntityDeletedEvent

Since platformized APIs only expose PATCH and not PUT we can't assume that the fields sent from the client are the actual diff.
This means that to generate a list of changed fields (as opposed to sent fields) one needs to traverse both objects.
We don't want to impose this on all developers and so we leave this traversal to the notification recipients which need it.

currentEntityAsJson

EntityUpdatedEvent

deletedDate

RestoreInfo

CreateStoresLocationRequest

CreateStoresLocationResponse

storesLocationId

DeleteStoresLocationRequest

DeleteStoresLocationResponse

GetOrCreateDefaultStoresLocationRequest

GetOrCreateDefaultStoresLocationResponse

GetStoresLocationRequest

GetStoresLocationResponse

QueryStoresLocationsRequest

Details on the paged set of results returned.

storesLocations

QueryStoresLocationsResponse

A location is a physical or virtual site where products are sold.

Date and time the Stores location was created.

createdDate

Whether the location is the site's default location.

defaultLocation

Location type.

+ `VIRTUAL`: Online store.
+ `PHYSICAL`: Physical location. For example, for POS.

locationType

name

Revision number, which increments by 1 each time the Stores location is updated.
To prevent conflicting changes,
the current revision must be passed when updating the Stores location.

Ignored when creating a Stores location.

revision

Date and time the Stores location was last updated.

updatedDate

Wix location ID.
Learn more about the [Locations API](https://dev.wix.com/docs/rest/business-management/locations/introduction).

wixLocationId

StoresLocation

LocationType

UpdateStoresLocationRequest

UpdateStoresLocationResponse

Pointer to the next or previous page in the list of results.

You can get the relevant cursor token
from the `pagingMetadata` object in the previous call's response.
Not relevant for the first request.

cursor

limit

CursorPaging

Number of items returned in the response.

count

Whether there are more pages to retrieve following the current page.

+ `true`: Another page of results can be retrieved.
+ `false`: This is the last page.

hasNext

CursorPagingMetadata

Cursor pointing to next page in the list of results.

Cursors

SortOrder

fieldName

order

Sorting

Filter object in the following format:
`"filter" : {
"fieldName1": "value1",
"fieldName2":{"$operator":"value2"}
}`
Example of operators: `$eq`, `$ne`, `$lt`, `$lte`, `$gt`, `$gte`, `$in`, `$hasSome`, `$hasAll`, `$startsWith`, `$contains`

filter

Sort object in the following format:
`[{"fieldName":"sortField1","order":"ASC"},{"fieldName":"sortField2","order":"DESC"}]`

sort

CursorQuery

Cursor token pointing to a page of results. Not used in the first request. Following requests use the cursor token and not `filter` or `sort`.

pagingMethod

Manage Products

Read Products

Manage Orders

Get StoresLocation

GetStoresLocation

Manage Stores - all permissions

Read Stores - all read permissions

Manage Restaurants - all permissions

Read v3 catalog

Manage v3 catalog

Read inventory in v3 catalog

Read Stores Locations in v3 catalog

Retrieves a list of up to 100 Stores locations, given the provided filtering, sorting, and cursor paging.
Pass supported values to the `fields` array in the request to include those fields in the response.


Query Stores Locations runs with these defaults, which you can override:

- `createdDate` is sorted in `DESC` order
- `cursorPaging.limit` is `100`

For field support for filters and sorting,
see [Stores Locations: Supported Filters and Sorting](https://dev.wix.com/docs/rest/business-solutions/stores/catalog-v3/stores-locations-v3/supported-filters-and-sorting).

To learn about working with _Query_ endpoints, see
[API Query Language](https://dev.wix.com/docs/rest/articles/getting-started/api-query-language),
and [Sorting and Paging](https://dev.wix.com/docs/rest/articles/getting-started/sorting-and-paging).

Stores Location Object