Solutions
Price monitoring, costed by the request
A pricing programme runs on one boring input, repeated a great many times: what did this URL say about this product, just now. We sell that repetition. The strategy, the matching and the decisions sit on top of it and stay with you.
What we do not offer
This is not a price monitoring platform. No scheduler, no product matching, no price extraction, no history store, no alerting and no repricing engine. No JavaScript rendering either, so a listing that fills its price in from a browser-side call will not have one in the HTML we return. And a retailer that blocks cloud address ranges outright will block us: every address we have is a datacenter address, and rotating within our own range does not change that answer.
The decision underneath the data
Pricing is expensive to get wrong in both directions. Undercut and you handed away margin you did not need to; sit high and you lost the sale to someone who moved first. Minimum advertised price enforcement, promotional response, assortment gaps and grey-market detection are all versions of the same question asked on different cadences.
What every version needs is an observation: a specific URL, a specific moment, a record of what came back. That is a small thing to buy and an annoying thing to operate at volume, which is why the collection layer is usually the part that gets outsourced.
Volume is the governing number
Your programme is sized by URLs times frequency. Ten thousand listings checked twice a day is twenty thousand fetches a day, and that number is the one that shows up on your invoice, because billing here is per request. One URL check is one request. /pricing carries the current figures and reads them live from the plan catalog rather than repeating a number that could drift.
The same arithmetic is why the response envelope reports the target's own status rather than only our own. A fetch that comes back with the target's 403 block page is still a fetch, and it arrives labelled status 403 instead of masquerading as a page. Count those separately: a run whose block rate is climbing needs a person looking at it, not a tighter retry loop.
Regional price display
Price is one of the most aggressively geo-varied things on the web, so the exit address is not a detail. Region is a query parameter on each call.
europe
AWS eu-west-1. Tax-inclusive display, euro and sterling pricing, and catalogues that differ from the US one.
us-east and us-west
AWS us-east-1 and us-west-2. Two US vantage points, which also gives you a second address when one is being throttled.
No other exits
There is no Asia-Pacific, Middle East or South America node. Pricing that is only shown to those regions is not observable through us.
Retries that do not double-charge
Timeouts are normal in a long collection run, and the usual fix — retry everything that did not return — is how you end up paying twice for one observation. Send an Idempotency-Key and a retry after a timeout is neither re-executed nor billed twice; the replay comes back marked Idempotency-Replayed: true so your pipeline can tell.
Failed fetches are not billed as successful ones. There is no request id in a fetch response, so nothing is looked up by ticket number: what a successful response does carry is device_id, region_used and public_ip — the node that fetched, the region that actually served it and the address the target saw. If something looks wrong, email support@roamingproxy.com with those three, plus the target URL, the time, and the error code if the call was refused rather than served.
What you build, and it is most of it
Product matching is the genuinely hard part of price monitoring and it is entirely yours: deciding that a competitor's listing is the same item as yours, across different titles, bundles and pack sizes. So is the extraction, the history store that makes yesterday's price available to compare against, the alerting, and any rule that changes your own price.
We are one call inside the first step. That is a smaller claim than the old version of this page made, and it is the true one.
When we are the wrong tool
Targets that block cloud ranges at the edge, listings that render their price client-side, anything behind a login, and anyone who wants a finished dashboard rather than a collection layer. In all four cases you will find out faster here than after an integration.
Questions
- Will it work on the retailers I care about?
- That depends on two things about each target: whether it blocks datacenter address ranges, and whether the price is in the HTML its server sends or drawn in by the browser afterwards. The playground in the dashboard lets you try a real URL before you build anything around it, which is the only way to find out honestly.
- Do you extract the price from the page?
- No. You get the response body as the target sent it. Selectors, currency parsing and stock-status detection are yours to write and yours to maintain when the target changes its markup.
- Do you keep price history?
- No. We store no response bodies at all, so there is nothing to look back at. Every price series you want has to be written to your own store as you collect it.
- How do I start a subscription?
- Card checkout is being enabled through our payment provider, which acts as merchant of record. Today a plan is activated after a short exchange — useful anyway for a monitoring programme, because volume is the thing worth agreeing up front. Email billing@roamingproxy.com.
Get a key
Create an account and mint an API key in the dashboard. The full endpoint reference — request shapes, parameters and error codes — is published at https://api.roamingproxy.com/v2/docs.