Do I need the dashboard to use the API?

Only to get a key and to read your billing. Everything on the data plane is an ordinary HTTPS call, and the API reference at api.roamingproxy.com/v2/docs is public.

Can I see a log of the URLs I fetched?

No, and that is on purpose. Egress nodes do not log target URLs or response bodies. What is recorded is what an invoice needs: request counts and byte counts.

Email billing@roamingproxy.com. There is no checkout button: subscriptions are granted after a human conversation, so the pricing page ends in a contact rather than a card form.

Where do I take a problem?

support@roamingproxy.com. There is no request id on the fetch path, so do not go looking for one — send what you actually have. Roughly when you sent it, the region you asked for, the target URL, and the error code from the response body. If a response envelope came back, region_used, device_id and public_ip from it are the three fields that narrow it down fastest on our side. We do not log target URLs, so that one we have to ask for.

Tools

The dashboard, screen by screen

cloud.roamingproxy.com is where an account gets its keys, tries a request without writing code, and reads back what it has been billed for. Every figure on it is a real read from the API, which is why a new account correctly sees a screen full of zeros.

Create an account See pricing

What we do not offer

There is no proxy pool manager on it, because there is no pool to manage: no IP blocklists, no sticky-session rules, no city or ISP targeting, no SOCKS toggles and no scheduler for recurring jobs. The dashboard also has no checkout screen: card checkout is being enabled through our payment provider, and until it is live a plan is activated after a short exchange, which is what /pricing says where a buy button would normally be.

API keys

Keys are minted here, scoped, and revocable one at a time. The two scopes are proxy, for the fetch path, and read. A key's secret is shown once at creation and stored hashed, so losing it means minting a new one rather than recovering the old.

Key management is deliberately not gated behind a subscription: you can create and organise keys before anything is entitled, because entitlement belongs on the call the key makes, not on the screen where you make the key. Rate limits apply per account, so extra keys are for separating environments rather than for throughput.

The playground

Send a real fetch from the browser and read the whole envelope with each field labelled: the body, the status the target answered with, the content type, the egress address the target saw, where the request landed after redirects, how many hops it took, the size of the body, how long the node took, and which region served it.

When a call is refused, the playground shows the refusal and its machine-readable code rather than a generic failure, so the first thing you learn about an error is the string you will branch on in your own code.

Usage

Metering is per request and queryable back over the API. The usage screen reads two things: metered quantities grouped by resource type, and un-invoiced usage priced against the rate card so you can see what is accruing before the period closes.

Nothing on it is simulated or seeded with a demo dataset. If you have made no requests, it shows none.

Invoices, credits and credit notes

Invoices are issued at period close with their line items, and the print view is the invoice document itself. Prepaid credit balance is shown alongside them, and credit notes are the correction path when money has already moved and something needs to be put right.

Amounts travel as integer minor units and are divided exactly once, at render; quantities travel as exact decimal strings rather than floats. That is a boring implementation detail right up until the moment a rounding error appears on somebody's invoice.

Webhooks and integrations

Register an endpoint, choose which billing events it receives, and read the delivery log for it. Deliveries are HMAC-signed, and the endpoint URL is SSRF-validated both when you register it and again at every single delivery — a hostname that resolved publicly yesterday can resolve to an internal address today.

The integrations screen carries the things that make the first call quick: copy-paste snippets with your own API base filled in, a generated Postman collection, and an MCP server. The MCP server is in our repository and is not published to a registry yet, which the screen says rather than implying a one-click install.

Questions

Do I need the dashboard to use the API?: Only to get a key and to read your billing. Everything on the data plane is an ordinary HTTPS call, and the API reference at api.roamingproxy.com/v2/docs is public.
Can I see a log of the URLs I fetched?: No, and that is on purpose. Egress nodes do not log target URLs or response bodies. What is recorded is what an invoice needs: request counts and byte counts.
How do I subscribe?: Email billing@roamingproxy.com. There is no checkout button: subscriptions are granted after a human conversation, so the pricing page ends in a contact rather than a card form.
Where do I take a problem?: support@roamingproxy.com. There is no request id on the fetch path, so do not go looking for one — send what you actually have. Roughly when you sent it, the region you asked for, the target URL, and the error code from the response body. If a response envelope came back, region_used, device_id and public_ip from it are the three fields that narrow it down fastest on our side. We do not log target URLs, so that one we have to ask for.

Pricing Rotating proxy Status Support

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.

Create an account Sign in