Liquorland AU Search, Catalog & Store Tools (Unofficial)

Search Liquorland Australia products, inspect the full navigation tree, enrich product cards with Bazaarvoice review data, and resolve store/location context in normalized output.

This is an unofficial actor and is not affiliated with Liquorland.

Supported operations

• categories
• category
• item
• search
• search_suggest
• locations
• suburbs
• nearby_stores

Operation guide

The Apify Console form shows the union of all supported fields, so the visible inputs do not change when you switch operation. Use the guide below to know which fields are required.

• categories Required: none Optional: state, includeRaw
• category Required: path or categoryPath or categoryId Optional: state, page, facets, sort, show, includeRaw
• item Required: url, or productId plus itemSlug Optional: state, includeReviews, reviewLimit, includeRaw
• search Required: query Optional: state, storeId, page, facets, sort, show, fallbackToSuggest, v, userId, clientId, includeRaw
• search_suggest Required: query Optional: state, v, includeRaw
• locations Required: query or postcode Optional: includeRaw
• suburbs Required: query or postcode Optional: includeRaw
• nearby_stores Required: lat, lon Optional: page, size, userId, authToken, userKey, includeRaw Note: advanced operation. It depends on a live anonymous Liquorland session exposing both userId and authToken, or on you supplying those values explicitly.

Validated starter examples

These are the safest first-run inputs I validated locally against the live site. They are the examples I recommend for private smoke checks and Apify Store saved tasks.

How categories work

categories is built from Liquorland's state-specific navigation endpoint /api/navigation/ll/{state} and preserves much more of the source tree than a flat "category URL" list.

Each row includes:

• kind One of category, landing_page, facet, group, or group_item
• category_supported true only when the row can be used directly with the category operation
• has_url Whether the row has a real URL/path
• facet_only true for filter-only rows from the navigation tree

That means /specials/* rows are still returned, but they are marked as kind=landing_page and category_supported=false, so users can see them without mistaking them for real API categories.

For the best UX:

• use categories first to inspect the state-specific tree
• use rows with category_supported=true for category
• keep /specials/* rows for merchandising insight, but not as category inputs

Example inputs

{
  "operation": "categories",
  "state": "nsw",
  "includeRaw": false
}

{
  "operation": "category",
  "path": "/beer",
  "state": "nsw",
  "page": 1,
  "facets": "",
  "sort": "",
  "show": 72,
  "includeRaw": false
}

{
  "operation": "item",
  "productId": "7705729",
  "itemSlug": "lorry-boys-low-carb-lager-can-375ml",
  "url": "https://www.liquorland.com.au/beer-and-cider/lorry-boys-low-carb-lager-can-375ml_7705729?uom=CTN24",
  "state": "nsw",
  "includeReviews": true,
  "reviewLimit": 3,
  "includeRaw": false
}

{
  "operation": "search",
  "query": "vodka",
  "state": "vic",
  "storeId": "2278",
  "page": 1,
  "facets": "",
  "sort": "",
  "show": 60,
  "fallbackToSuggest": true,
  "v": 2,
  "includeRaw": false
}

{
  "operation": "search_suggest",
  "query": "wil",
  "state": "vic",
  "v": 2,
  "includeRaw": false
}

{
  "operation": "locations",
  "query": "3000",
  "includeRaw": false
}

{
  "operation": "suburbs",
  "query": "3000",
  "includeRaw": false
}

Advanced nearby stores example

nearby_stores is useful, but it is not a reliable first smoke because Liquorland does not always expose the anonymous session token needed for that inventory endpoint. Use it after validating the actor with the starter examples above.

{
  "operation": "nearby_stores",
  "lat": -37.8133386,
  "lon": 144.9708234,
  "page": 1,
  "size": 10,
  "includeRaw": false
}

Output

• Dataset: normalized products or structured navigation/location/store rows
• Key-value store OUTPUT: run summary with source, operation, success, total, errors, proxy, and monetization

Notes

• search now tries the product-search API first even without storeId, but store-aware runs are still best when you provide a real storeId.
• A practical way to get storeId is locations or nearby_stores.
• If Liquorland blocks the full search API, the actor can degrade gracefully to search_suggest so the run still returns useful product candidates.
• item supports URL-driven fallback recovery and can optionally enrich products with Bazaarvoice review stats and a small recent-review sample.
• locations and suburbs map to the public suburb search endpoint and are aliases of the same capability.
• nearby_stores uses the authenticated inventory endpoint and returns richer store metadata when the anonymous session bootstrap succeeds or when you provide userId plus authToken explicitly.
• If nearby_stores cannot bootstrap those credentials, the actor returns a structured unsupported payload with a hint instead of a raw failure.
• Default proxy strategy is direct.
• The runtime is prepared for future pay-per-event monetization.