Liquorland AU Product, Offers & Location Scraper

Scrape Liquorland Australia product search results, prices, offers, categories, reviews, and store/location context. Use this Liquorland scraper for alcohol retail price monitoring, product research, review enrichment, and store-aware ecommerce workflows.

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

Supported operations

• categories
• category
• item
• search
• search_suggest
• locations — postcode/suburb place suggestions, not verified store branches
• suburbs — alias of the same place-suggestion lookup
• nearby_stores — advanced, credential-required operation

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 Note: returns geographic place suggestions, not physical Liquorland store records or numeric store IDs.
• suburbs Required: query or postcode Optional: includeRaw Note: alias of locations; results are geographic suggestions rather than verified branches.
• nearby_stores Required: lat, lon, userId, authToken Optional: page, size, userKey, includeRaw Note: advanced credential-required operation. Supply credentials from your own valid Liquorland session; automatic anonymous session bootstrap is not reliable.

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 not a stable anonymous workflow. Liquorland's inventory endpoint requires session credentials, so use it only when you can provide userId and authToken from your own valid Liquorland session. Without them the Actor returns a structured unsupported summary rather than failing the run.

{
  "operation": "nearby_stores",
  "lat": -37.8133386,
  "lon": 144.9708234,
  "userId": "YOUR_SESSION_USER_ID",
  "authToken": "YOUR_SESSION_AUTH_TOKEN",
  "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.
• Supply a known numeric Liquorland storeId when store-aware search matters. The public locations and suburbs lookup does not provide this ID.
• 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 return place suggestions, not verified Liquorland branch records.
• nearby_stores uses an authenticated inventory endpoint and is intended only for callers who provide their own valid userId plus authToken.
• 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.