Use cases
You get the response. The parsing is yours.
Extraction has two halves: getting the bytes, and turning the bytes into fields. We do the first half and hand you the second, whole and untouched. If you were hoping for a service that returns a tidy product object, that is not what this is, and the rest of the page assumes you would rather know now.
What we do not offer
No extraction service: we do not return fields, schemas, normalised units or matched SKUs across retailers, and there is no CSV or scheduled export. No JavaScript rendering, no image or PDF retrieval, and no session or cookie support, so anything behind a login, a postcode selector or a cart stays out of reach.
Find the endpoint the page already calls
Almost every modern catalogue loads its own product data over HTTP after the page shell arrives. Open the product page with your browser's network tab, filter to XHR, and look for the request that carries the price, the variant list or the stock flag.
If that request is a GET, its URL is the best target you will find: it returns JSON, it changes far less often than the markup, and the response is a fraction of the size, which matters when your list has fifty thousand rows in it. If it is a POST, we cannot reach it — our node performs a GET and sends no body to the target.
When only HTML exists
Look for structured data embedded in the page before you write CSS selectors. A JSON-LD block describing the product, or microdata attributes on the markup, is far more stable than a class name that exists because a designer needed a hook for a border.
Where you do have to use selectors, write them against something semantic and assert on what you extracted. A price parser that returns null rather than a wrong number is worth more than one that never fails.
The fields you get back
The response is a JSON envelope around the target's answer, and the diagnostic fields are there so your pipeline can make decisions without parsing anything.
result, status, content_type
The body, the target's own HTTP status, and its Content-Type verbatim. Check the latter two before parsing the first.
final_url, redirects
Where the fetch ended and how many hops it took. A variant URL that redirects to a parent product shows up here.
bytes, elapsed_ms
Body size and how long the node spent. Useful as a cheap anomaly signal across a large catalogue.
region_used, public_ip, device_id
Which region actually served, the address the target saw, and which node did the work.
Text only, so no images
Response bodies are decoded to text. HTML, JSON, XML and CSV come through intact. Images, PDFs and anything else binary do not — they arrive as replacement characters, which is worse than an error because it looks like data.
Collect image URLs while you parse and fetch the images themselves with an ordinary HTTP client. Very large pages have a second limit to know about: responses over the node's size cap are refused with response_too_large rather than truncated, so you never silently parse half a page.
The identity you present
The one request header forwarded to the target is your User-Agent, so whatever you send on the call to us is what the retailer sees. GET /v2/user-agents/ is the catalog the proxy itself uses if you would rather pick from a list than invent one. Being identifiable and reasonable tends to work better than being clever.
Questions
- Do you return structured product JSON?
- Only if the target does. We return the target's response as it came. When the target has a JSON endpoint you get JSON; when it has HTML you get HTML and write the parser.
- Can I download product images through the proxy?
- No. Bodies are decoded as text, so binary content is destroyed in transit. Extract the image URLs from the page and fetch them separately.
- What about pages that need a session or a delivery postcode?
- Out of reach. The fetch takes a URL and nothing else — no cookies, no headers beyond User-Agent, no POST body. If the data only exists after state is established, this is not the right tool.
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.