A public Vero profile hands a plain HTTP client the whole page: 2,393 words in 265,121 bytes from the United States, and the same 2,393 words from Germany and the United Kingdom, with the posts, captions and 25 images in the HTML before any script runs. Rendering the same URL in a browser returns 2,421 words for 331,650 bytes, 28 more words for 25 percent more traffic. There is no public API and the oEmbed endpoint returns a 404. On Vero the setting is plain HTTP through any residential exit, and the line to remember is that every profile response carries a robots tag of noindex, noimageindex, noarchive.
Vero is the ad-free, algorithm-free, subscription-funded network that photographers adopted in 2018, and nobody in the proxy trade writes about it because there is nothing to sell: autocomplete returns no proxy demand on the name at all. That makes it the cleanest measurement in this series, and the one with an unusual answer about what "public" means. Here is what a proxied client gets, and what the platform says about it.
The profile is fully server-rendered, and identical from three countries
We audited vero.co/vero, the platform's own account, through residential exits in three countries, once without JavaScript and once rendered.
| Exit country | Plain HTTP | Rendered in a browser |
|---|---|---|
| United States | 2,393 words, title VERO on VERO, description, Twitter card | 2,421 words, identical title and description |
| Germany | 2,393 words, identical | 2,421 words, identical |
| United Kingdom | 2,393 words, identical | 2,421 words, identical |
Six passes, two numbers. The plain page is the profile: the display name, the bio with a link to the community newsletter, the recent posts with their captions, and the images. The server that produced it identifies itself as Express, and it sends the whole document at once, which is why the browser has nothing to add but 28 words of interface. There is no canonical tag, and the og:url is the relative path /vero rather than an absolute URL, which a link-preview parser should expect to fix up itself.
The exit country changes nothing: not the words, not the title, not the tags. That is rarer than it sounds among the platforms we have measured, where the same URL gave TikTok four different shells from four countries and Minds a page that hydrated from Germany and not from the United States. On Vero there is no country to pin for content; the only reason to choose an exit is latency.
The browser adds 28 words for 25 percent more bytes
We weighed both fetch modes from the United States. Plain HTTP: 265,121 bytes, 4,962 extractable words and 25 images in Markdown, on the second attempt. Rendered: 331,650 bytes, 4.6 seconds, 5,246 words and 49 images, because the browser triggers lazy image loads and pulls the second screen of the feed. The 284 extra Markdown words are image alt text and a few more post captions.
That is the whole case for skipping the browser here: it costs a quarter more bandwidth and a browser slot to gain a second page of posts you can also get by requesting the next page, and it adds no field the plain page lacks. On a target where the render is useless the instruction is to say so and spend less, and this is that target.
There is no public API, and the platform says so by omission
We looked for an API surface the way we do on every platform. A request to vero.co/oembed with a profile URL returned a 404 in 16,965 bytes, the app's not-found page. The platform publishes no developer documentation, no rate-limit page and no oEmbed discovery tag in its HTML. The Help Center describes a product built on a subscription model with a chronological feed and no engagement algorithm, and Vero's own terms describe the phone verification every account goes through so that only real people join. The public web profile is the entire public surface.
So the architecture is one route: the profile page over plain HTTP, paged. Compare that with Bluesky, whose public API returns a kilobyte where the page returns two and a half megabytes; on Vero the page is the API, and at 265 kilobytes it is a reasonable one.
Public, but noindex and noarchive: what that means for a dataset
Every profile response we received, from all three countries, carried the meta tag robots: noindex, noimageindex, noarchive. The robots.txt at vero.co is a 1,498-byte Squarespace template that gives the same rule set to 29 named crawlers and to every other user agent: no crawling of configuration, search, account and API paths and of query-string variants, and no exclusion of profile paths at all. Read together, the two files say something precise: crawlers may fetch a profile, and must not index it, must not index its images, and must not keep a cached copy.
The Terms of Use add the line that applies to everyone, not just crawlers: by accessing the service you have made a contract with Vero and agreed to the terms "even if you're just visiting the public part of the Service", and accounts are for real people, verified by phone. That is the plain answer to what a proxy can do on Vero. Reading a public profile is what the platform serves; building an index, an image corpus or an archive from it is what the platform's own tags ask you not to do; and automating accounts is out.
What this is properly for: checking that your own profile and posts render from the countries your members live in, monitoring a known list of public creators you follow, verifying a partner's presence before a collaboration, and brand-safety checks on public captions, all at a human pace and without retaining copies beyond the check. Posts remain their authors' content and personal data wherever the reader sits.
What it costs, counting a gigabyte as one billion bytes
| How you fetch it | On-wire bytes | What you get | Per GB | Cost at $0.80/GB |
|---|---|---|---|---|
| Profile, plain HTTP, any exit | 265,121 | 2,393 words, posts, captions, 25 images | ~3,772 profiles | $0.00021 |
| Profile, rendered, any exit | 331,650 | 2,421 words, 49 images, 4.6 seconds | ~3,015 profiles | $0.00027 |
| oEmbed probe | 16,965 | A not-found page | n/a | n/a |
Check 5,000 public profiles a day for a month over plain HTTP: about 40 GB, about $32 at the residential Basic rate. Rendered, about 50 GB and about $40 for 28 more words each. The difference is small because the plain page is already the full page; the reason to skip the browser on Vero is not the money but the browser slot and the 4.6 seconds.
If you would rather not run the fetch layer, our web scraping API returns the profile as Markdown for $0.0002 per page with no browser, through the same residential exits, with the second attempt handled: our plain scrape needed two attempts where the audit's plain pass needed one. On Vero do not pay for the $0.001 rendered mode.
The setting that works on Vero
- Network: residential, Basic at $0.80/GB. Residential exits in the United States, Germany and the United Kingdom read the full profile over plain HTTP; nothing in eight passes needed more than a household address.
- Fetch mode: engine: tls, plain HTTP, retry budget 2. 2,393 words in 265,121 bytes; the render returns 2,421 words for 331,650 bytes and a browser slot.
- Country to pin: none. The same 2,393 words came back from all three exits, so the number that changes when you do not pin is zero; choose the exit by latency.
- Public API: none. The oEmbed endpoint returns a 404 in 16,965 bytes, and no developer documentation exists; the profile page is the public surface, and it is tagged noindex, noimageindex, noarchive.
- When the proxy is not enough: the web scraping API at $0.0002 per page returns the profile as Markdown with the retry handled; for cross-platform listening alongside Vero, the Reddit collector returns public posts as rows with no fetch layer on your side.
- Free tier: every account gets $2 of free API usage per month, which covers 10,000 profile pages at the plain-HTTP rate.