Pinterest gives a proxied client more than the vendors selling Pinterest proxies think, and less than a browser costs. On 28 September 2026 we fetched one public profile fifteen times through residential exits in the United States, Germany and Brazil. A plain HTTP client received 1,304,978 bytes with the h1, the description, ProfilePage JSON-LD and the board grid, 107 extractable words. Rendering the same page cost 2,628,042 bytes and 33 seconds for 151 words, and from Brazil the render never hydrated at all. The exit country picked the domain, www, de. or br., before a single script ran.
Search for Pinterest proxies and Google offers you an unblocker
The head term hardly exists. Autocomplete returns "pinterest content policy", "pinterest owned by" and three variants of "pinterest proxy site", which are the school-network unblockers. The first page of results is nine vendor pages selling IPs for registering many accounts and running Pinbots and autopin software, one Reddit thread, and, at rank ten, a Pinterest developer page about a different proxy entirely: Pinterest's own image proxy, the service that fetches images from your website when someone pins them, so that the request you see in your logs comes from Pinterest and not from the user. If you arrived here because of that page, it is a Pinterest feature, not a product, and there is nothing to buy.
The data intent lives under "pinterest scraper": api, github, python, board, image, profile, search. That is the question this article measures: what does pinterest.com hand a client that arrives through a proxy, which surfaces are worth the bytes, and what the exit country does to the answer.
A profile is 1.3 MB of plain HTML, and the useful part is in the head
We audited pinterest.com/nasa/ with and without JavaScript from each of the three exits, and weighed it over plain HTTP.
| Fetch | Exit | Final host | Bytes | Words | Title |
|---|---|---|---|---|---|
| Profile, no JavaScript | US | www.pinterest.com | 1,304,978 | 107 | NASA (nasa) - Profile | Pinterest |
| Profile, rendered | US | www.pinterest.com | 2,628,042 | 151 | NASA (nasa) - Profile | Pinterest |
| Profile, no JavaScript | DE | de.pinterest.com | 1,294,444 | 127 | NASA (nasa) – Profil | Pinterest |
| Profile, rendered | DE | de.pinterest.com | 181 | NASA (nasa) – Profil | Pinterest | |
| Profile, no JavaScript | BR | br.pinterest.com | 129 | NASA (nasa) — Perfil | Pinterest | |
| Profile, rendered | BR | br.pinterest.com | 129 | NASA (nasa) — Perfil | Pinterest | |
| oEmbed, no token | US | www.pinterest.com | 375 | JSON | NASA |
Read the byte column first. A profile page is 1.3 megabytes over plain HTTP, and only a fraction of that is content: the page ships its application and its state to every client, whether or not the client can run it. Inside, the parts that matter for a data job are server-rendered: the h1 "NASA", the description "Explore the universe and discover our home planet with the official NASA boards on Pinterest", the canonical link, an Open Graph block, a ProfilePage JSON-LD object, and the board grid, 11 headings and 23 images in the plain HTML. What the plain HTML does not carry is a follower count. Pinterest keeps counters out of the head, which is the one way it is stingier than Facebook, Instagram or Threads.
The rendered rows are the ones to learn from. From the United States, the browser downloaded twice the bytes, ran for 33.3 seconds, and lifted the word count from 107 to 151: the pin grid populating. From Germany, 127 to 181. From Brazil, 129 to 129: the page returned 200, looked complete, and never hydrated inside the capture window. That is the expensive failure mode of rendering a single-page app, and we have seen it before on Bluesky: no error, just a shorter page you might store as if it were the whole profile. Count words per exit, never trust the status.
The exit country picks the domain before any script runs
We sent no Accept-Language header and changed nothing between exits. Pinterest redirected the German exit to de.pinterest.com and the Brazilian exit to br.pinterest.com, translated the title into "Profil" and "Perfil", and left the canonical pointing at www.pinterest.com/nasa/ in all three cases. The description stayed in English because it is the account's own text.
Three consequences for a collector. First, a URL list built from one country's crawl will be redirected in another country's crawl, so store the canonical, not the final URL. Second, the interface strings differ per exit, so a parser keyed on the English word "Profile" in the title breaks silently from Germany; key on the canonical and the JSON-LD instead. Third, and this is the one that decides the pool, the render hydrated in two countries and not in the third. Pin the exit country per job, so that every row in a dataset was read from the same Pinterest, and treat a rendered word count equal to the plain count as a retry, not a result.
The oEmbed endpoint exists, and it carries no counts
Every profile page advertises an oEmbed endpoint in its Link header, and it answers a client with no token: www.pinterest.com/oembed.json?url=https://www.pinterest.com/nasa/ returned 375 bytes of JSON in 2.1 seconds, cached for 259,200 seconds, three days.
{"version":"1.0","type":"rich","provider_name":"Pinterest",
"title":"NASA","author_name":"NASA",
"author_url":"https://www.pinterest.com/nasa/",
"width":450,"height":900,"html":"<iframe src=... grid=nasa ...>"}It resolves a profile URL to a display name and an author URL, and hands you an embed. It has no follower count, no pin count, no board list. For validating a list of handles it is 3,480 times cheaper than the profile page; for anything else it is not the tool. The same shape holds on TikTok, where oEmbed returns a name in 668 bytes and nothing you could put in a spreadsheet.
The official API is a different thing. Pinterest API v5 is, in Pinterest's own words, only available to authenticated and authorized users: every call carries an OAuth access token scoped to a user who granted your app permission. It reads that user's boards, pins and analytics. It does not read other people's public profiles at scale, which is why the "pinterest scraper api" query exists at all.
robots.txt is an allowlist of 330 named bots, then Disallow everything
pinterest.com/robots.txt is 37,852 bytes and it is built backwards from most sites. It opens with a comment, "Allowlist your bot: https://help.pinterest.com/bot-submission-form", then lists roughly 330 named user agents, Googlebot and bingbot alongside Applebot, DuckDuckBot, Slackbot, TelegramBot, WhatsApp, Mastodon, meta-externalfetcher, Google-NotebookLM and hundreds of monitoring and SEO tools, and gives that whole group the same set of path rules: pins, boards and profiles allowed, search, homefeed, settings, followers lists, comments and the business tools disallowed. A separate block gives AdsBot-Google, LinkedInBot, SnapchatAds, meta-externalads and Taboolabot Allow: /, so that ad-verification crawlers can see everything. Then the last block:
User-agent: *
Disallow: /Followed by about a hundred Sitemap: lines: image pins by engagement tier, video pins, product pins, board links, user links, seasonal pins, shopping. Pinterest is simultaneously publishing a detailed map of its public content and telling any client it has not named to stay out of all of it. The bot submission page is the door: 118,644 bytes for a form that asks who you are. It is worth noting who is not on the allowlist: none of the AI training crawlers by name, and not a single generic scraping framework.
The Terms of Service say the same thing in one sentence, in section 2a: users agree not to scrape, collect, search, copy or otherwise access data or content from Pinterest in unauthorized ways, such as by using automated means without express prior permission. So the honest position is this. A public profile is technically readable over plain HTTP, and the canonical, the description, the JSON-LD and the board list arrive without a browser. Permission to collect it at scale is a contractual question that robots.txt and the Terms both answer with "ask first". Reading a handful of profiles to verify a creator or check how your own pins render in another market is one thing; a crawl of the user sitemap is what the last two lines of robots.txt are about. Under United States law the two questions are separate, and we cover that ground in is web scraping legal in the US; Pinterest's own position does not depend on it.
What a Pinterest read costs
Every number here came through residential proxies on the Basic line at $0.80/GB, counting a gigabyte as 10^9 bytes.
| Job | Bytes per request | Requests per GB | Cost per request |
|---|---|---|---|
| Profile, no JavaScript | 1,304,978 | 766 | $0.0010 |
| Profile, rendered, hydrated | 2,628,042 | 380 | $0.0021 plus 33 s of browser |
| oEmbed, name and author URL | 375 | 2,666,666 | $0.0000003 |
A gigabyte holds 766 profile pages over plain HTTP or 380 rendered ones, and the rendered ones take 33 seconds each and fail to hydrate in one exit of three. Ten thousand profiles is 13 GB and about $10 over plain HTTP; rendered, 26 GB, $21, and 92 hours of browser time. Pinterest is the heaviest plain page in this series, 1.3 MB against 1.03 MB for a Threads profile, 663 KB for a Snapchat profile and 128 KB for a Telegram feed page, because it ships the whole application to every client and renders the least of it on the server. Budget by bytes, and never budget the render: on this platform it doubles the cost and adds 44 words.
The setting that works on Pinterest
- Network: residential proxies, Basic line, $0.80/GB. Fifteen fetches from three countries returned complete plain-HTTP pages; the Premium ($2.20/GB) and Mobile ($2.30/GB) lines returned nothing extra on logged-out reads, and the cost driver is the 1.3 MB page, not the address.
- Fetch mode:
engine: tls, plain HTTP. The profile returns 107 words, the h1, the description, the canonical, the ProfilePage JSON-LD and the board grid in 1,304,978 bytes; rendered it returns 151 words in 2,628,042 bytes after 33 seconds, and from one exit in three it returns the plain count again. Use oEmbed, 375 bytes, to resolve handles to names. - Country: pin the exit per job. The same URL becomes www.pinterest.com from the United States, de.pinterest.com from Germany and br.pinterest.com from Brazil, with the title translated; store the canonical, which stays on www, and parse the JSON-LD rather than the interface strings.
- When the proxy is not enough: there is no Pinterest collector in our catalogue. The web scraping API without rendering returns the profile as clean Markdown from $0.0002 per page, with a CSS extraction schema for the board list and the option to return the page's own state as JSON; failed requests are never billed. To see the no-JS and rendered views of your own URL list side by side, the SEO Audit API fetches both in one call at $0.0012 per URL, which is exactly the measurement in this article.
- Free tier: every account gets $2 of free API usage per month, which is 10,000 profile pages through the scraping API before you pay anything.
Read the profile over plain HTTP, pin the country, keep the canonical, resolve handles through oEmbed, and read the Terms before you read the sitemap. For the platform in this series where the head does carry the counts, compare Threads; for the one that answers in 2,810 bytes with no page at all, Discord.
What we will not help you do
Nine of the ten results on this keyword sell the same thing: register many Pinterest accounts through proxies and run autopin bots on them. We will not write that. Pinterest's Terms prohibit automated access without permission, its spam policy covers automated pinning, and no proxy restores a suspended account. What proxies legitimately serve on Pinterest is creator and brand research on public profiles, checking that your own pins, boards and shopping ads render correctly in each market, which the domain redirect makes a real per-country question, monitoring for counterfeit or unauthorised use of your product images, and reading your own analytics through the API you are authorised for.