Solutions
Market research when the evidence is on the public web
Web data is observational evidence: a record of what firms publish, not a sample of what customers believe. Knowing which of your research questions falls on which side of that line saves more time than any collection tool, so this page starts there.
What we do not offer
There is no research platform here — no dashboards, no analysis, no survey or panel data, no consumer records and no search engine results. Egress is three regions, not a country list: us-east, us-west and europe. If your study needs an exit in Asia-Pacific, the Middle East or South America, we do not have one and cannot pretend otherwise.
The questions this evidence answers
Public web data is good at what is offered, at what price, with what claims attached, and how all three changed over time. Which competitors entered a category, which quietly left it, what a sector's pricing pages say this quarter that they did not say last quarter, which features moved from a roadmap page to a product page.
It is bad at motive. It will not tell you why someone bought, what they would have paid, or what they think of you. Those need primary research, and treating a scraped corpus as a substitute for it is the most common way this kind of project produces a confident wrong answer.
Sampling, and the address problem underneath it
A finding is only as good as the collection behind it, and collection fails in two ways that both look like nothing went wrong. The first: a source rate-limits you partway through, the back half of your sample is missing, and the gap is correlated with collection order rather than with anything real. The second: the source varies by geography and you did not control for it, so you compared a European page against a US one and called the difference a market difference.
Region is an explicit parameter on every request rather than an account setting, so which exit you asked for is a decision you make. GET /v2/proxy/regions is the authoritative list and is health-gated: a region whose endpoints are all known to be down is not advertised.
Asking for a region is not the same as being served by it, and the difference is the one thing a geography-sensitive study must not get wrong. If the region you named has no endpoints in service the fetch fails immediately with a region-out-of-service error. But if its endpoints are in service and all of them fail at fetch time, the request fails over to a region that answers and returns 200. The response field region_used names the region that actually served. Record region_used with every observation rather than the region you asked for — it is the difference between a European price point and a US one relabelled.
Reproducibility is the requirement nobody writes in the brief
Six months later someone will ask you to re-run the study, or ask why a number moved. Both questions need the collection to have been accountable at the time. Four things in the API exist for that.
The target's own outcome
Each response reports the status the target answered with, its content type, the byte count, the redirect hop count and the final URL. Record those alongside what you parsed, so a row in your dataset can be audited rather than trusted.
Idempotent retries
An Idempotency-Key means a retry after a timeout is not re-executed and not billed twice, so a flaky network does not become duplicate observations.
Stable error codes
Every data-plane refusal carries a machine-readable code, and the vocabulary is pinned against the published API reference by a test — a branch you wrote against a code cannot silently change meaning between deploys.
Metering you can reconcile
Per-request usage is queryable over the API, so the number of observations in your dataset can be checked against the number of fetches you paid for.
Three regions, and what they are actually worth
The europe exit is the one that earns its keep in research work. Tax-inclusive price display, currency, localised copy, consent-banner variants and outright redirects into a country subdirectory are all things a site decides from the requesting address. Fetching the same URL from europe and from us-east and diffing the two is a cheap, direct measurement of that.
Two US exits are useful for a duller reason: when one address is being throttled by a source, the other is a second way in, and coast-level differences occasionally exist in delivery and availability data.
What you still build
The sampling frame, the parsers, the panel design if you are tracking the same sources over time, the storage, and the statistics. We supply observations one URL at a time. Turning them into a study is the research, and that has never been the part a proxy could do for you.
Questions
- Can you supply the data instead of the connection?
- No. We return the target's response and nothing more. There is no dataset product, no archive and no analysis layer; parsing, storage and interpretation are yours.
- Can I research an Asian or South American market?
- You can fetch sites in those markets, if they serve our addresses. What you cannot do is exit from those regions — we run nodes in us-east, us-west and europe only, so any geography-sensitive measurement is limited to those three vantage points.
- Do you hold historical data I can query?
- No. Nodes do not log target URLs or response bodies, so there is no archive to query. Metering records request and byte counts, which is what an invoice needs and nothing more. If you want a time series, you have to store your own observations from day one.
- Does choosing a region change what a site shows me?
- It changes the address the site sees the request come from. Whether that changes the content is entirely the site's decision, and the only way to know is to fetch from two regions and compare.
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.