HM - Hennes Mauritz API: Review & Developer Guide

What the HM - Hennes Mauritz API does and who it is for

The HM - Hennes Mauritz API is an unofficial third-party wrapper around H&M's public-facing product data. It exposes regions, categories, and product listings in a structured, queryable format, sparing developers the effort of scraping or reverse-engineering the retailer's front end. The API is hosted on a marketplace (not by H&M directly), so integration is governed by the marketplace's terms rather than H&M's own developer program.

The primary audience is developers building fashion-adjacent applications: price-comparison tools, wardrobe apps, affiliate storefronts, retail analytics dashboards, or any project that needs a continuously updated view of H&M's assortment. With 3,158 subscribers and a popularity score of 9.9 out of 10, it is clearly the go-to option in its niche.

Endpoint walkthrough

The API exposes eight GET endpoints across three resource groups.

Regions

GET /regions/list returns the list of geographic regions that H&M officially supports. This is typically the entry point for any integration: you need a valid region to scope subsequent category and product requests to the correct locale, currency, and assortment.

Categories

Two category endpoints are available:

• GET /categories/v2/list — the current, actively maintained version.
• GET /categories/list — the original version, still present but implicitly superseded by v2.

Category data represents H&M's taxonomy (e.g., Women → Tops → T-shirts), which is essential for building navigation trees or filtering product queries by department.

Products

This is the most feature-rich group and contains five endpoints:

• GET /products/v2/list — the primary product listing endpoint. It supports sorting, filtering, and name-based search, making it flexible enough to replicate most browse-and-search flows from H&M's website.
• GET /products/v2/search-by-barcode — accepts a barcode and returns the matching product. Useful for point-of-sale integrations, inventory tools, or mobile apps with a scan feature.
• GET /products/detail — fetches full detail for a single product, presumably including description, images, pricing, and available variants.
• GET /products/list — deprecated predecessor to v2/list.
• GET /products/search-by-barcode — deprecated predecessor to v2/search-by-barcode.

The two deprecated endpoints should be avoided in new integrations; the v2 variants are the safe path forward. All endpoints use GET, so no write operations are supported — this is a read-only data API.

Latency and reliability

The reported average latency is 2,169 ms. That is on the higher end for a REST API and is worth factoring into your architecture. For background data-sync jobs — nightly catalog refreshes, for example — this is not a problem. For synchronous user-facing features (real-time search autocomplete, instant barcode lookups), you will want to cache aggressively and set appropriate client timeouts. The good news is that the reported average success rate is 100%, suggesting that when the API does respond, it responds correctly.

Pricing breakdown

The freemium model makes it easy to prototype without a credit card, but the free tier's 500-request monthly ceiling is restrictive for anything beyond a proof of concept.

BASIC suits exploration and local development. At 500 requests per month you can browse a region list, pull the category tree, and page through a handful of product listings — but you will exhaust the quota quickly if you are crawling a full category.

PRO at $20/month is the first realistic production tier. Ten thousand requests per month works for a small affiliate site or a personal project that refreshes product data a few times per day rather than continuously.

ULTRA at $50/month triples the PRO quota to 30,000 requests. The rate limit stays the same at 10 requests per second, so the upgrade buys sustained throughput over a full month rather than burst capacity.

MEGA at $300/month jumps to 500,000 requests and a slightly higher rate limit of 15 per second. This tier is aimed at commercial applications — comparison engines, large affiliate networks, or analytics platforms — that need to mirror a significant portion of H&M's catalog on a regular cadence.

There are no overage mentions in the published pricing, so you should monitor consumption carefully as you approach a plan's ceiling.

Practical use cases

• Affiliate and fashion e-commerce: Pull product listings including images and prices to build curated storefronts linked back to H&M.
• Price tracking: Periodically poll products/v2/list across categories to detect price changes and push alerts to subscribers.
• Wardrobe or outfit apps: Use the full category hierarchy alongside product details to let users browse or virtually try on H&M items.
• Barcode scanning: The products/v2/search-by-barcode endpoint enables mobile apps to look up a physical H&M item by scanning its tag — handy for resale platforms or style-saving features.
• Retail analytics: Aggregate category and product data over time to analyze H&M's assortment decisions, seasonal rotation, and pricing strategy.

Limitations and things to check before integrating

Unofficial status: This is a third-party API, not an official H&M developer product. The underlying data depends on H&M's website continuing to expose it in the same structure. Breaking changes on H&M's side could affect availability without notice.

Latency: At roughly 2.2 seconds average, synchronous use cases require a caching layer. Consider storing product data locally and refreshing on a schedule rather than fetching on demand per user request.

Deprecated endpoints: Avoid products/list and products/search-by-barcode (non-v2) in any new code. They are still present but should be treated as sunset candidates.

Request quotas vs. catalog depth: H&M's catalog spans thousands of SKUs across dozens of categories and multiple regions. Even the MEGA plan's 500,000 monthly requests may not cover a full daily re-index of the entire catalog at fine granularity; plan your fetch strategy accordingly.

Terms of use: Since the data originates from H&M's website, review both the marketplace's terms and H&M's own terms of service before building a commercial product, particularly one that republishes product imagery or pricing.

Getting started

1. Subscribe to the BASIC plan on the marketplace — no cost, instant access.
2. Call GET /regions/list to discover valid region codes.
3. Pass a region code to GET /categories/v2/list to retrieve the full taxonomy for that market.
4. Use GET /products/v2/list with category and region parameters to page through products; filter or sort as needed.
5. For individual product pages in your app, call GET /products/detail with the product identifier returned from the listing endpoint.
6. Implement a local cache with a TTL that makes sense for your use case — daily for most catalog data, more frequently if you are tracking prices — to stay well within your plan's monthly request budget.

Once you have validated your integration and estimated your real-world request volume, choose the paid tier that fits your cadence before going to production.