Resources
How to get help, and what to send
Support is email, answered by the people who wrote the service. There is no ticket portal to learn and no tier to escalate through. What there is instead is a short list of details that turns a report into a fix, and this page is that list.
What we do not offer
There is no live chat widget, no 24/7 rota and no published response-time commitment, because we will not advertise a number we have not measured and cannot yet guarantee. The voicemail line on the contact page is exactly that — a box that takes messages, with no answering hours claimed for it. There is also no paid onboarding, training programme or professional-services arm. If you need a contractual support SLA, say so at support@roamingproxy.com and we will tell you honestly whether we can sign one.
Where to write
support@roamingproxy.com for anything technical: failing requests, error codes you cannot interpret, keys and scopes, regions, integration questions, and abuse reports about traffic coming from one of our addresses.
billing@roamingproxy.com for invoices, prepaid credits, credit notes, plan changes and quotes. Subscriptions are granted after a conversation rather than through a checkout page, so this is also the address to use if you want to start.
Three things that answer most questions faster than we can
None of this is a brush-off. Each of these is a live surface, not a document someone maintains by hand, so it is current in a way an email reply cannot be.
The error code
Every data-plane refusal carries a stable code alongside its message, and the reference lists what each one means and what to do about it. missing_scope, unknown_region and target_not_permitted are all fixed by changing the request.
The live endpoints
GET /v2/proxy/regions tells you what can serve right now, and GET /v2/proxy/status reports fleet health. A region missing from the first is a region we will not serve.
The API reference
https://api.roamingproxy.com/v2/docs is public, generated from the running service, and covers authentication, the quickstart, every error code, idempotent retries and the rate limits.
What to put in a report
A good report is one round trip. Send these and we can usually find the exact request in our own records without asking you anything.
The request you sent
The full URL including the region query parameter, the target URL in the body, and whether you sent an Idempotency-Key.
When
A timestamp with its timezone, or a UTC one. A window of a few minutes is fine; 'yesterday afternoon' is not.
What came back
The HTTP status of our response and the code field from the body, verbatim. If it was a 200, tell us the status field inside the envelope too, because that is the target's answer and it is usually the real subject of the report.
Which node served it
region_used, device_id and public_ip from the envelope. Together these identify the exact egress that handled your fetch, which is the closest thing we have to a request id on the proxy path.
Whether it reproduces
Does the same URL work from another region? Does a different URL work from the same one? Those two answers separate a target-side block from a fleet problem immediately.
Your account email
So we can find the account. Never send the key itself, and never paste it into a screenshot.
Request ids, precisely
The social data API returns a request_id in its envelope; quote it if your report is about a social endpoint. The proxy fetch envelope does not carry one, and we would rather say that than have you hunt for a field that is not there. For a fetch, the combination of timestamp, region_used, device_id and the target URL is what we search on.
If you think a key has leaked
Revoke it in the dashboard first, then tell us. Keys are individually revocable and scoped, so killing one does not disturb the others, and revocation takes effect on the next request rather than at some cache expiry. Do not email us the key so we can revoke it for you; that only puts it in one more inbox.
What we will not do
We will not tell you a target is fetchable when we do not know that it is, and we will not sell you a plan to work around a block that a datacenter address cannot get past. If the honest answer to your question is that this product does not solve your problem, that is the answer you will get.
Questions
- How quickly will I get a reply?
- We do not publish a response time because we have not measured one we would be willing to be held to. Mail is read by the people who built the service, and a report containing the details above is answered materially faster than one that does not.
- Is there a status page I should check first?
- There is no hand-maintained page of green ticks. GET /v2/proxy/regions and GET /v2/proxy/status answer the same question from the running system, and you can wire both into your own monitoring.
- Who do I contact about a privacy or abuse matter?
- Abuse and security reports go to support@roamingproxy.com. Privacy requests, data-subject requests and compliance questions have their own pages on this site, linked below, and those routes exist because they need a paper trail rather than a thread.
- Can you help me write my scraper?
- We will answer questions about our API, error codes, regions and retry behaviour in as much detail as you need. We do not write or debug your parsing code, and there is no consulting arm that does.
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.