The user-agent catalog, and why the list is curated

What a record contains

Each entry has the user-agent string itself plus the device class it belongs to, the browser, the operating system, and an optional share figure carried over from the source the list is built from. The response is a data array with a count, paged with skip and limit, so you can read the whole catalog in a loop and cache it.

The read is authenticated and takes an rp_ key carrying the read scope; the fetch path takes the proxy scope. Those are two different scopes checked against a default-deny table, so a proxy-only key is refused here. Mint one key with both if you want to do both, or keep them separate if you would rather the key in your crawler could not read anything else. Writing to the catalog is an administrative operation, not a customer one.

How the string reaches the target

The User-Agent header on your call to POST /v2/proxy/fetch is the User-Agent the egress node sends to the target. It is the only header a caller can influence on the outbound request; the rest of the header set is fixed. That is a deliberately short allowlist rather than a pass-everything default.

So the rotation is something you drive, and that is the honest description of it: pull the catalog once, keep it, and pick a string per request or per run. If you send no User-Agent at all, the node uses its own default, which is not a browser string — fine for an API you own, less useful against a site that varies its markup by client.

Why a curated list beats a generated one

A string assembled at random is usually internally inconsistent: a Chrome version that never shipped, Safari on a Windows platform token, a mobile fragment attached to a desktop OS. Inconsistency is more conspicuous than commonness — an ordinary string that millions of real browsers send draws no attention, while an impossible one is trivially detectable by a lookup table.

There is a second, less defensive reason to choose deliberately. Plenty of sites serve materially different markup to a mobile client: lighter pages, different pagination, sometimes different data. Picking a mobile string on purpose can be the difference between parsing a heavy desktop page and a light one, and picking a desktop string can be the difference between seeing a full table and seeing a collapsed summary.

Strings age

Browser versions ship constantly, so a user-agent string has a shelf life. The catalog is refreshed from its upstream source as an administrative operation, and the practical advice is to read it periodically rather than pasting one string into a constant in 2026 and still sending it in 2028.

Questions

Does the proxy rotate the user agent for me automatically?

The string that goes out is the one you send on your call. Read the catalog, pick per request, and you have rotation you can reason about and reproduce. Send nothing and the node falls back to its own default identifier.

Do I need an API key to read the catalog?

Yes, and it needs the read scope — the fetch path needs proxy. A key carrying both works on both; a proxy-only key is refused on the catalog, which is the thing people trip over here, so check the scopes on the key before you debug the call. The read is paginated with skip and limit and returns a count alongside the data.

How many strings are in the catalog?

The count field in the response tells you, and that is the only place worth reading it from — the number changes when the catalog is refreshed, so a figure printed on a marketing page is wrong shortly afterwards by construction. An earlier version of this page advertised a fingerprint count instead, which got both halves wrong: these are user-agent strings, not fingerprints, and nothing in this path emulates a browser. Read count.

Can I add my own strings?

Not through the customer API — creating and updating entries is restricted to administrators. If you need a specific string in the catalog, email support@roamingproxy.com, or simply send that string as your User-Agent header on the fetch call.

Related