Every ecommerce manager in Indonesia has the same recurring question and no reliable way to answer it: is anyone selling my product cheaper than I am, right now?
Not last month. Not according to a spreadsheet somebody updated in July. Right now, on the listing a customer is looking at.
This is a walkthrough of building that check as an automated job. It runs unattended, it costs about a cent per product checked, and the whole thing is four HTTP calls. Every figure below was measured against the live API rather than estimated.
Why this is harder than it looks
The naive approach is to open the competing listings and read the prices. That works for ten SKUs once. It does not work for four hundred SKUs every morning, and it certainly does not work when a competitor drops price for six hours during a flash sale and puts it back before anyone checks.
The second problem is subtler. Shopee's own listing page shows a price, but a product with variants has a range, and the number a shopper actually pays depends on which variant they pick. If your monitoring reads the wrong field, you will be comparing your single-SKU price against a competitor's cheapest variant and concluding you are being undercut when you are not.
The endpoint that matters
Magpie's Scraping API has one endpoint built for exactly this, and one property that makes it usable in automation: get_pc is the only Shopee endpoint with no approval gate and no working-hours restriction.
That distinction is worth understanding before you build anything. Most Shopee collection endpoints — search listings, merchant catalogues, variant-level sold counts — are approval-gated and only process between 08:00 and 18:00 GMT+8. They are excellent for analysis. They are useless for a job that has to run at 3am. get_pc runs whenever you call it.
Building it
Step one: get the two IDs. Every Shopee product URL ends in the same pattern:
https://shopee.co.id/Some-Product-Name-i.503260895.28941237
The first number is the shop id, the second is the item id. A regular expression over your competitor URL list gets you both in one pass.
Step two: submit the fetch. One POST per product, returning a task id:
POST /v1/shopee/get_pc/submit with {"region": "id", "item_id": "...", "shop_id": "..."}
Valid regions are id, sg, th, ph, my, vn, tw and br — the API validates the value before charging you, so a typo costs nothing.
Step three: poll. GET /v1/shopee/get_pc/retrieve/{task_id} until status stops being pending. Back off as you go — 10 seconds, then 30, then 60. Tight polling loops achieve nothing except noise.
Step four: read the price correctly. This is where most implementations go wrong. The price in the payload is an integer scaled by 100,000. A listing at Rp 89,000 comes back as 8900000000. Divide by 100,000 or your entire report will be off by five orders of magnitude.
The payload also carries a field called is_lowest_price_at_shopee, which answers the original question directly and which almost nobody uses because almost nobody reads that far into the response.
What it costs
get_pc bills 8 credits per product. Credits are USD 0.00125 each at the entry tier, so a single price check is one cent. Monitoring 400 competitor SKUs every morning is 3,200 credits a day — about USD 4, or roughly USD 120 a month.
Beyond a handful of products, switch to get_pc_bulk, which takes a CSV of items in a single job, and attach a schedule to it so the whole thing runs nightly without anyone touching it.
The report worth building
Do not produce a list of prices. Produce a list of exceptions: every product where a competitor's price is at or below yours, with your price, theirs, and the gap. Sort by gap size. Ten rows a category manager can act on beats four hundred rows nobody reads.
Two refinements that make it genuinely useful. First, log the history — a competitor who undercuts you for six hours every Friday is running a promotion pattern, and you cannot see a pattern from a single snapshot. Second, add your own margin floor, so the alert distinguishes between "we are being undercut" and "we are being undercut below the point where matching makes sense".
Where the panel comes in
Live price checking answers what is happening today. It cannot tell you which products are worth watching in the first place — you are guessing at the SKU list.
That is the other half. Magpie's Data API serves a maintained monthly panel of the same marketplaces, and a single export ranks every SKU in a category by GMV. Pull the top hundred, and you have a monitoring list built from what actually sells rather than from what you assumed matters. Analysis picks the list; live collection keeps it current.
The two run on one API key and one prepaid wallet, which is the practical reason to do both from the same place.
Start here
The complete prompt for this workflow — including the parsing rules that stop an AI assistant misreading the sold-count field — is published in the Magpie agent skill, along with nine other recipes. Point Claude or ChatGPT at it, give it your key, and describe the products you want watched.