Network
How to tell whether we are up
There is no status page with a row of green ticks on it, because a hand-maintained status page tells you how someone felt about an incident rather than whether your next request will work. The API answers that question directly.
Ask the API
GET /v2/proxy/regions returns the regions we are willing to sell right now. A region we have fresh evidence against is omitted outright rather than returned with a warning flag nobody reads, so the list is something you can act on without parsing a mood.
GET /v2/proxy/status reports the fetch path's own health. Both are part of the published API reference, so you can wire them into your own monitoring instead of watching ours.
What a failure looks like
Every refusal on the data plane carries a stable machine-readable code alongside its human-readable message, and those codes are pinned against the published API reference by a test — so a code you branch on cannot quietly change meaning between deploys.
A failed fetch is not billed as a successful one. Usage records are written for requests that actually served.
Health is per region, not per site
A listed region is one we have no fresh evidence against. It is dropped only when the health cache shows every one of its endpoints failing — a single endpoint we know nothing about leaves the region listed, because a partial sweep is not proof and pulling a working region on one costs you an exit for nothing. Those readings are cached with a short lifetime rather than taken live on your request, which keeps a health probe from being charged to your latency budget.
So a region can be listed and still fail on the next fetch, and that is the state failover exists for rather than a contradiction in the list. If the endpoints in the region you asked for fail mid-request, the fetch is served from another region and the response carries region_used naming the one that actually served it. Nothing is silent about it — but nothing errors either, so if the exit country is part of what you are measuring, assert on that field rather than on the region you sent.
Refusals are a different path and each carries its own stable code. A region with no enabled endpoints at all is refused immediately with region_out_of_service instead of walking your request through a list of dead URLs, and a region name we do not recognise is refused with unknown_region. Both come back fast enough to branch on rather than hanging.
Check at start-up
Read GET /v2/proxy/regions when your process boots rather than hardcoding a region list.
Assert on region_used
Every fetch response names the region that served it. That is the field to check when the exit matters, because failover can make it differ from the one you asked for.
Check on refusal
If a fetch comes back region_out_of_service or unknown_region, re-read the list before retrying elsewhere.
Note what you sent
Region, target URL and roughly when. Social API responses also carry a request_id; proxy fetches do not.
If something is wrong
Email support@roamingproxy.com with the region you asked for, the target URL, roughly when you sent it, and the status and error code you got back. Social API responses also carry a request_id in their envelope; include it when you have one. Proxy fetch responses do not carry one today.
We do not log target URLs or response bodies, which is why we have to ask you for them. That is a deliberate trade rather than an oversight: your traffic is not sitting in our logs, and the cost is that a support conversation starts with you telling us what you sent.
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.