datawebotBlibli product data: seller offers, variants & IDR prices
Understand Blibli product and seller records, category-based variants, IDR offer prices, seller reputation, delivery estimates and seller API boundaries.
One Blibli product may have several seller offers
Blibli’s buyer help says different sellers may set different prices for the same type of product. A useful record therefore keeps the shared product, each seller’s offer, the selected option and the time of observation distinct. Compare an offer only with its seller, option and page context attached.
Scroll to compare →
| Record level | Fields to preserve | How to interpret it |
|---|---|---|
| Buyer-facing product | Name, brand, category, specifications and full product URL | The URL and title identify the observed page; neither is a universal seller SKU. |
| Seller offer | Seller/store name, displayed IDR price and visible offer or availability state | Blibli says different sellers may price the same product type differently; keep their offers separate. |
| Selected option | Visible option label and value, such as a category-defined size or color | The option is meaningful only with the product and seller offer it belongs to. |
| Observation | Source URL, seller, option, displayed currency and capture time | A page observation can change and does not establish what another seller or later visit shows. |
Seller SKUs and public product pages describe different records
Blibli’s Seller API describes product operations in seller and store context. Its current Product List V3 returns main-product-level records, while the documentation points to Product Detail V2 for variant detail. Product History V2 requires a valid seller Product SKU and describes changes to that seller’s product; it is not a history of prices across competing public offers.
Scroll to compare →
| Reference | What it identifies | Safe use |
|---|---|---|
| Consumer product URL | The buyer-facing page and content visible there | Retain the full URL as observation evidence; do not treat its slug as an account SKU. |
| Seller Product SKU | A product in the seller’s account context | Keep the seller/store scope with it; it does not identify every merchant’s offer. |
| Product List V3 | Main-product-level seller catalog records | The current API documentation says to use Product Detail V2 when variant detail is needed. |
| Product Detail V2 | Variant detail for a specified seller product | Use the field names and account scope in the current seller documentation; do not infer IDs from option text. |
| Product History V2 | Changes tied to a valid Product SKU, over the documented 30-day or one-year window | This is seller-product history, not public cross-seller price monitoring. |
Category attributes determine how seller variants are represented
Blibli’s current Create Product V3 flow asks sellers to use Category Attributes V2. The category metadata indicates whether an attribute creates variants or is a special attribute, and the API places those values in different request fields. Descriptive product attributes remain product details. This is a seller catalog model, not a promise that every buyer-facing category exposes the same option structure.
Scroll to compare →
| Attribute role | Seller-side treatment | Interpretation boundary |
|---|---|---|
| Variant-creating attribute | When Category Attributes V2 marks `variantCreating` true, Create Product V3 uses the `variantAttribute` field. | Only treat a value as a variant dimension when the current category metadata defines it that way. |
| Special attribute | Create Product V3 uses the `specialAttribute` field when the category marks the attribute as special. | Do not collapse special attributes into descriptive details or variant IDs. |
| Descriptive attribute | Keep the category label and value with the product details. | A technical specification does not create a separate item by itself. |
| Illustrative option | Color or size can be an option when the selected category defines it as variant-creating. | This is an example of the rule, not a claim about a particular live Blibli listing. |
Keep seller reputation separate from product reviews
Blibli’s help describes seller information on the product detail page: an Official Store marker when applicable, seller badges, location, operating hours and seller rating. These are seller-level signals. Record the displayed label and seller identity, then keep them separate from the product’s own reviews or rating.
Scroll to compare →
| Visible signal | What to record | Boundary |
|---|---|---|
| Official Store marker or badge | Exact badge text beside the selected seller | It is a seller status signal, not a product attribute or proof of product quality. |
| Seller profile | Seller name, location, operating hours and seller rating when shown | A seller rating describes the seller profile, not the product review score. |
| Product review | Product-level rating or review count when separately displayed | Do not attribute product reviews to the seller score or join the two without evidence. |
| Offer price | Displayed IDR amount, seller, selected option and capture time | Keep price changes and seller identity together; avoid treating promotion copy as a guaranteed saving. |
A delivery quote belongs to a destination and logistics choice
Blibli’s shipping help says the delivery fee and estimated receipt date appear after a shopper selects a logistics service in the delivery and payment view. Keep those values with the destination scenario, chosen service, selected offer and observation time. Do not turn one displayed quote into a nationwide rate or delivery guarantee.
Scroll to compare →
| Delivery field | Observation to preserve | Limit |
|---|---|---|
| Destination | City or delivery scenario used to view the offer | One destination does not describe delivery cost or availability for all locations. |
| Logistics choice | Selected service or carrier label shown by Blibli | Different services can produce different fees and estimates. |
| Displayed fee and estimate | Visible amount and estimated receipt date after the service is selected | An estimate can change and is not a guaranteed delivery date. |
| Capture time and offer | When the quote was viewed and which seller/option was selected | Keep the quote attached to the relevant offer rather than the catalog product alone. |
Review Blibli’s terms before systematic collection or reuse
Section 2.2 of Blibli’s Terms & Conditions says users may not systematically take site content to create or compile a collection, database or directory by automated or manual means without written permission. The same section also restricts certain copying, redistribution and commercial use. Attribute this boundary to Blibli’s current terms; public visibility and Seller API credentials do not by themselves establish permission for a separate compilation or reuse purpose.
Scroll to compare →
| Question | What the source says | Practical reading |
|---|---|---|
| Systematic collection | Section 2.2 expressly covers automated and manual methods used to build a collection, compilation, database or directory. | The clause names systematic site-content collection; do not treat a public page as permission. |
| Written permission | The same section says written permission is required for that systematic compilation. | Review the intended purpose and applicable permission before planning collection or reuse. |
| Seller API scope | The Seller API documents seller-account product, variant and history workflows. | Seller API credentials are distinct evidence from permission to compile buyer-facing marketplace content. |
Content reviewed 2026-09-29.