A Sephora scraper that treats each shade as its own record. One foundation can carry dozens of SKUs, and only shade-level data tells you which are actually in stock.
Delivery is CSV, JSON, XLSX or an API endpoint, on the schedule you set - daily, weekly, or tied to a launch calendar. The normal shape is two linked tables: one row per product keyed on the P identifier, one row per SKU keyed on skuId, joined on the product id. Reviews come as a third table.
We run and maintain the crawler. When Sephora changes its markup, repairing it is our work and not a ticket for your team. Each run ships with a short report: rows delivered, fields that came back empty, and SKUs that were present last time and are not present now.
A Sephora record has two natural levels, and we keep them separate rather than flattening one into the other. The product level holds what is true of the whole item. The SKU level holds what changes shade by shade.
Reviews on Sephora are served through Bazaarvoice rather than by the storefront that renders the product, so the review payload and the product payload are separate collections with separate failure modes. We treat them as two jobs and report on them separately.
We do not guess at fields. If Sephora stops publishing one, the column arrives empty and the run report says so, rather than the crawler quietly refilling it from last week's values.
Sephora reviews carry more structure than retail reviews usually do. Reviewers self-declare attributes when they post, Sephora shows them beside the review, and shoppers can filter the list by them. The set includes skin type, skin tone, eye color, hair color, hair type and an age range. Set against the star rating, that lets a brand or category team segment a review corpus properly.
One quirk is worth planning for. Sephora labels reviews written in exchange for product and lets a shopper filter them out, but that filter does not change the headline average star rating on the page. The rating you read and the rating implied by the reviews you kept are two different numbers. Storing the incentivised flag per review lets you recompute the second one. The headline figure alone will not.
The attributes are self-reported and optional, so coverage is partial and a field can be blank. We return the blank rather than inferring a value. They are also personal data. Our default output is limited to product and review content in aggregate. Reviewer names, profile identifiers, avatars and profile links are excluded by default and never written to the delivered files. Attribute fields arrive as counts and distributions across a review set, not as a per-person record. Where a client operates in the EU or handles data about EU residents, the GDPR applies, and the scope of what we return is agreed in writing before the first run. We do not give legal advice and we do not build person-level profiles.
Sephora is a beauty and cosmetics retailer owned by LVMH. It sells third-party brands alongside its own label, through physical stores, through sephora.com, and through a set of separate regional storefronts. For anyone planning extraction, the useful question is not how large the catalogue is but how it is shaped.
A product page is addressed as /product/{slug}-P{productId}. The product id carries a leading P, and P97989778 and P507645 are both real examples of the form. Browse and category pages sit under /shop/, so a path such as /shop/makeup-cosmetics is a category root rather than a search result. The slug is descriptive and can be rewritten. The P identifier is the stable join key between two runs, and it is the one we key on.
Underneath that sits a second identifier. Every buyable variant has its own numeric skuId, and Sephora addresses it as a query parameter on the same product URL, in the form /product/{slug}-P{productId}?skuId={skuId}. One page, many purchasable items. That single design decision is what makes Sephora unlike a general retailer to crawl, and it drives the rest of this page.
Availability is scoped to a place as well as to a SKU. Sephora asks for a zip code before it will report whether an item is held in a given store, and same-day delivery cutoff times are set per zip code. A stock value recorded without the postcode it was read under is not reproducible, so we store the two together.
Get a Quote
Developers
Customers worldwide
Pages extracted
Hours saved for our clients
€199 / one-time
setup fee - included
€169 / mo
setup fee €499
€229 / mo
setup fee €499
€349 / mo
setup fee €499
€549 / mo
setup fee €799
The reason to scrape Sephora carefully rather than quickly is the variant explosion. A single complexion product can carry dozens of shades. Each one is a separate purchasable item with its own skuId, its own swatch and its own stock state. A crawler that writes one row per product URL discards most of that and keeps a single price that may not apply to the size the buyer actually wants.
Stock is where this bites hardest. A product page stays live and buyable while individual shades sell through, so an availability flag read at product level is close to meaningless. The shade that is gone is the fact worth having. It tells a brand team which end of a range is under-supplied and it tells a category buyer which shade is moving. Read at product level, that signal never appears at all.
Price behaves the same way. Size variants are separate SKUs sitting behind one product id, so a single product row cannot hold a single correct Sephora price. Discontinuation behaves the same way too: ranges are trimmed shade by shade, and a SKU can vanish from the selector while the product page carries on unchanged. Only a run that stores skuId as the primary key can report that a shade left the range, as opposed to a page that merely changed.
Scraping supplement products from iHerb.com with full details, including descriptions and packaging variations.
Learn More
Daily scraping of lowest prices for 150K products on Allegro.pl to support marketplace pricing and margin optimization.
Learn More
Regular monitoring of Ralph Lauren clothing, footwear, and accessories sold across Amazon subdomains: AE, DE, ES, FR, IT, NL, PL, UK.
Learn MoreLearn how to use web scraping to solve data problems for your organization
If you sell online, run a marketplace, or advise e-commerce clients, you already know why eBay matters: it’s one of the few places where big retailers compete side by side with thousands of small merchants and private sellers.
E-commerce teams do not just need “some” competitor data anymore. They need a continuous stream of real prices, discounts, stock levels, reviews, and seller behavior from the platforms that actually shape their markets.
Amazon provides valuable information gathered in one place: products, reviews, ratings, exclusive offers, news, etc. So scraping data from Amazon will help solve the problems of the time-consuming process of extracting data from e-commerce.
ScrapeIt is a managed web scraping agency. We build the crawler, run it on your schedule, watch it, and hand over clean files. There is nothing to install and no library to learn. The work is billed as a service, so the cost of a site change is ours to absorb rather than yours. Tell us the categories, the countries and the refresh rate you need, and we will come back with a field list and a sample before anything is committed.
No. There is no open product catalogue API that a business can sign up for and query. A developer portal exists at developer.sephora.com, but it is described as a service catalogue for internal microservices, not a data product for outside buyers. The various Sephora APIs sold on API marketplaces are third-party scrapers using the name. We have no partnership or affiliation with Sephora either. We collect what is publicly visible on the site and deliver it in a structured form.
One row per shade by default. Every SKU gets its own row keyed on skuId, carrying its own shade name, size, price and stock state, with the product id as the foreign key back to the parent product. A collapsed product-level table can be shipped alongside it if your reporting needs one, but the shade table is the source of truth.
Yes, one site at a time. Sephora runs separate regional storefronts with their own catalogues, currencies and assortment, so each is configured as its own source and delivered as its own table with the site recorded on every row. Prices are not comparable across storefronts without that column. Within a single site, in-store availability is scoped to a zip code, so we also record the postcode each stock check ran under.
No. Reviewer names, profile identifiers, avatars and profile links are excluded by default and never reach the delivered files. What arrives is review text, star rating, date, and the self-declared attribute fields reported in aggregate across a review set. If you need a scope narrower or wider than that, we agree it in writing before the first run.
Faster than most retail. Launches and limited editions arrive on a marketing calendar, sale events move prices across whole categories at once, and shades drop out of a range with no announcement. Weekly is the floor for assortment tracking. Daily is normal if you are watching price or stock, and around a sale event we can run more than once a day.
Step 1 - Make a Request
You share your needs, expectations, and desired timeframe. We’ll suggest the best solution based on your request and budget.
Step 2 - Configuring Custom Web Crawlers
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Step 3 - Collect and Deliver
Once you approve the sample, we launch the project and start full data collection. We gather, filter, and structure the data for easy use, delivering it on time in your preferred format.
Step 4 - Maintain and Support
Our team manages ongoing processes, monitors website changes, and supports all data extraction cycles. We can also help integrate data into your systems or create dashboards to simplify analysis.
Scrapeit Sp. z o.o.
10/208 Legionowa str., 15-099, Bialystok, Poland
NIP: 5423457175
REGON: 523384582
