The Warehouse NZ Scraper

Scrape product data from The Warehouse New Zealand thewarehouse.co.nz in a clean, structured format.

This actor supports two scraping modes:

• Search mode — scrape products from one or more keyword searches.
• URL mode — scrape from pasted Warehouse search, category, or product URLs.

It can collect product cards, enrich records from product detail pages, extract review data where available, and optionally export product summaries to connected apps through MCP connectors.

What this actor is for

Use this actor when you need structured product data from The Warehouse NZ without manually copying product pages or search results.

It is useful for:

• product research
• price monitoring
• catalog discovery
• ecommerce analysis
• marketplace tracking
• review collection
• internal product workflows

The actor can discover products from search and category pages, or enrich specific products when you already have the exact product URLs.

Output

Each product record can include:

• product URL
• product ID
• title
• brand
• price
• price range text
• currency
• availability
• main image
• full image gallery
• breadcrumbs
• category path
• marketplace flags
• seller name, where available
• rating summary fields
• whether the product is currently on special, and the offer end date when the site shows one
• the specials collection the product was browsed from, when using a specials category
• feature and benefit highlights, when detail enrichment is enabled
• product details, when detail enrichment is enabled
• customer reviews, when review extraction is enabled

The output is written to the default Apify dataset and can be exported as JSON, CSV, Excel, or through the Apify API.

Specials

Search mode includes an optional Specials category selector to browse The Warehouse's own promotional collections directly, instead of a keyword search. Matching products are returned with isOnSpecial set, and offerEndsAt populated when the site publishes an end date for that offer.

The Warehouse does not display an original/"was" price anywhere on the site — not on search results, specials pages, or product pages — so this actor does not fabricate one. isOnSpecial and offerEndsAt are the real signals the storefront itself asserts.

Reviews

Review extraction is optional.

When customer reviews are available, the actor normalizes them into a consistent structure, including fields such as:

• id
• productId
• rating
• title
• body
• authorAlias
• publishedAt
• verifiedPurchaser
• badges
• secondaryRatings
• vote counts

Not every product exposes review data. If no reviews are available, the product record is still saved normally.

Input highlights

Key input fields include:

• mode — choose search or url
• queries — search terms for search mode
• specialsCategory — browse one of The Warehouse's Specials collections instead of a keyword search
• urls — Warehouse search, category, or product URLs for URL mode
• fetchDetails — enrich product cards using product detail pages
• fetchReviews — fetch normalized customer reviews
• maxReviewsPerProduct — limit the number of reviews collected per product
• sortBy — sort search results by relevance, price, rating, newest, best sellers, or name
• maxItems — maximum number of products to save. Leave empty or set 0 for unlimited; this is the run's only default cap.
• maxPages — leave empty or set 0 (default) to walk every result page for each query/URL; the walk stops naturally when the storefront has no next page or a page repeats no new products, or sooner if maxItems is reached. Set a number only for an explicit page cap.
• resumeFromRunId — optional. Paste a prior run ID or dataset ID to continue a large walk-all pull: products already saved by that run are skipped, so this run only appends new items.
• incrementalMode — optional. Turn on for recurring/scheduled monitoring of the same search or URL set; see Resume & recurring updates.
• stateKey, emitUnchanged, emitExpired — incremental mode controls; see Resume & recurring updates.
• proxy — proxy configuration
• mcpConnectors — optional MCP connector IDs for app export
• notionParentPageUrl — parent Notion page URL for Notion export
• maxNotifyListings — maximum number of products sent to connectors

Sorting options

Search mode supports the following sort options:

• relevance
• price ascending
• price descending
• top rated
• newest
• best sellers
• name ascending
• name descending

URL mode

URL mode accepts:

• search result URLs
• category URLs
• direct product URLs

This is useful when you want to scrape a specific Warehouse page or enrich known products instead of starting from keyword search.

Detail enrichment

When fetchDetails is enabled, the actor visits product detail pages to improve the quality and completeness of each record.

Detail enrichment can add or improve:

• product description
• attributes
• feature and benefit highlights
• image gallery
• breadcrumbs
• category path
• availability
• marketplace and seller fields

Detail enrichment is recommended when you need higher-quality product records rather than lightweight search-result data.

Export to your apps with MCP connectors

You can optionally send a copy of scraped product summaries into the apps you already use through Model Context Protocol connectors.

Supported connector targets include:

• Notion
• Airtable
• Linear
• Apify

To use connector export:

1. Authorize a connector in Apify under Settings → Integrations.
2. Add one or more connector IDs to mcpConnectors.
3. If exporting to Notion, set notionParentPageUrl.
4. Use maxNotifyListings to limit how many products are sent to connectors in a single run.

Connector export is a side channel only:

• it does not change the dataset output
• it does not block a successful scrape
• connector failures are logged and skipped

What gets sent to connectors

Each connector receives a condensed, human-readable product summary, including fields such as:

• title
• product URL
• price
• availability
• brand
• seller
• key product fields

The full structured JSON record always remains available in the Apify dataset.

Typical use cases

• Scrape Warehouse NZ search results by keyword.
• Monitor prices and availability for selected products.
• Collect product and review data for ecommerce research.
• Enrich known product URLs with detail-page data.
• Send product summaries into Notion for research tracking.
• Push product records into Airtable for manual review.
• Trigger internal workflows using Apify or MCP-connected tools.
• Keep the full dataset in Apify while mirroring a smaller working set into operational apps.

Output notes

• By default (maxPages empty or 0), search mode walks the full result set for each query, URL, or Specials category — it stops on its own once the storefront has no next page or a page stops returning new products, or sooner once maxItems is reached. Set maxPages to a number only when you want an explicit page cap below that.
• URL mode supports search, category, and product URLs.
• Detail enrichment improves product descriptions, attributes, images, breadcrumbs, category paths, and availability.
• Review extraction is optional because not every product exposes review data.
• If mcpConnectors is empty, the actor writes only to the default Apify dataset.

Resume & recurring updates

Two different things, both under the same input section:

• resumeFromRunId — continues one specific interrupted run. Pass the ID of a previous run (or its dataset) and this run loads the product URLs it already saved, skips them, and appends only new products to a fresh dataset. Leave it empty for a normal run. Use this after an interrupted large walk-all pull, or to continue a catalogue pull across separate runs.
• incrementalMode — for recurring/scheduled monitoring of the same search or URL set (e.g. a daily run). The actor remembers the previous run of the same search itself, in its own key-value store, and classifies every product as NEW, UPDATED, UNCHANGED, REAPPEARED, or EXPIRED against that remembered state. Off by default; the first incremental run returns everything as NEW. See resumeFromRunId above if you instead need to continue one specific interrupted run.

When incrementalMode is on, each dataset record also carries:

• changeType — NEW / UPDATED / UNCHANGED / REAPPEARED / EXPIRED
• changedFields — which fields changed, for an UPDATED record
• firstSeenAt / lastSeenAt — when this product was first and most recently seen

State is keyed on a hash of mode, queries, urls, specialsCategory, sortBy, fetchDetails, fetchReviews, and includeUnavailable, so two differently-configured searches never share a baseline. Set stateKey to name a monitoring campaign explicitly, or to deliberately share state across an otherwise-different setup.

emitUnchanged and emitExpired are both off by default because they return — and bill — extra rows: unchanged products you already have, and synthetic EXPIRED rows for products no longer found. EXPIRED rows are only produced once a run has fully scanned the tracked search — never when maxItems/maxPages capped it, or when resumeFromRunId was used.

The detail-enrichment surcharge is charged only for a product that is actually pushed to the dataset — a product suppressed by incremental mode (an UNCHANGED row with emitUnchanged off) is never charged, even though its detail page may still have been fetched to compute the comparison.

The actor also checkpoints its own progress internally, so if a run is interrupted by a platform migration or resumed with Resurrect, it picks back up without re-saving (and re-charging for) products it already wrote. This checkpoint is separate from incrementalMode's cross-run state.

Local checks completed

The following checks were completed successfully:

• npm run typecheck
• npm run build
• live search mode
• URL mode
• sort coverage
• detail enrichment
• review extraction
• walk-all pagination natural stop (no page-count cap)
• resumeFromRunId fail-fast on an unreadable run/dataset ID
• migration/Resurrect checkpoint clears to null on a clean run