GETTR Proxies: What 17 Fetches Show

GETTR is a small network: in Pew Research Center's survey, one in ten US adults had heard of it and 1% said they regularly get news there. Its biggest audience outside the US is in Brazil. For a proxy buyer it is worth a closer look, because what the website serves and what its app API serves are very different. On 1 October 2026 we fetched GETTR seventeen times through residential exits in the United States, Germany and Brazil. The website sits behind Imperva and needed three attempts per profile. Without JavaScript a profile returns 8,793 bytes of metadata; rendered, it returns 3.8 MB. The JSON endpoints the app uses answered on the first attempt every time: 1,029 bytes for a profile, 60,273 bytes for its latest twenty posts.

What people search for, and what nobody measures

Google has no autocomplete at all for "gettr proxies". "gettr scraper" completes only to "gettr" and "gettr usa inc", and the brand name to "gettr apk" and "gettr search". The first page for "gettr proxies" contains no proxy or scraping page: Pew Research, the App Store, Reuters, the New Yorker, Politico, Vox, Wikipedia, the Australian eSafety Commissioner and an arXiv paper. The related searches are "Is GETTR free", "GETTR account", "Gettr reddit" and "GETTR com login".

The people who actually collect GETTR data are mostly researchers, journalists and brand-safety teams. The arXiv paper from 2021 describes GETTR's API as open but undocumented and reports collecting 4.2 million posts and comments from 419,000 users through it. Nothing on the results page says what that surface looks like today through a proxy, how much it weighs or what the bot protection does. The rest of this article answers those questions.

What GETTR serves a proxied client

Request (1 October 2026)	Exit	Result	Bytes
Profile /user/gettr, plain HTTP	US	200 after 3 attempts, Imperva challenge on the first two	8,793
Same profile, plain HTTP	Brazil	200 after 3 attempts, same challenge	8,797
Same profile, rendered	US	200, 9.6 s, 569 words of content	3,812,748
api.gettr.com/s/uinf/gettr (profile JSON)	US	200, first attempt	1,029
api.gettr.com/u/user/gettr/posts, 20 posts	US	200, first attempt, 823 ms	60,273
Same posts endpoint	Brazil	200, first attempt, 1,493 ms	60,273
gettr.com/robots.txt	US	200	648
api.gettr.com/robots.txt	US	404, JSON error	31
gettr.com/terms	US	challenge, escalated to a browser, terms text not in the page	2,395,043

The HTML profile page without JavaScript contains the title, a description cut at 120 characters, a canonical URL, a robots meta of "index, follow" and a JSON-LD block of type Person. Our audit counted 37 words of content and no h1. The posts appear only after rendering: 313 words from the US exit and 305 from Germany. The response headers show how it is built: x-cdn: Imperva, cache-control: public, max-age=300 and a cache key of the form user:profile:/user/gettr:lang:en_us. The HTML is cached at the edge for five minutes per language, so polling it more often than that returns the same bytes.

A single post page behaves differently. Without JavaScript, /post/p3ovsap252c returned 42 words, a title made from the post text, and JSON-LD of types SocialMediaPosting, BreadcrumbList and VideoObject. Rendered, the title fell back to the generic "GETTR - The Marketplace of Ideas". For a single post, the plain HTTP version is the better source: the structured data is already there, and the browser replaces it.

The app's JSON API sits on api.gettr.com. The profile endpoint returns the display name, description, location, creation timestamp, verification status, follower and following counters and pinned posts in about 1 KB. The posts endpoint with max=20 returns twenty posts with their stats and author data in 60 KB. Both answered on the first attempt from both countries, with no challenge. You can check which protection a target uses with our ../../tools/waf-detector/ before you choose a proxy type.

Which proxy GETTR actually needs

Rotating residential is enough for everything public. Every request in the table went through a rotating residential exit, and Imperva let all of them through, including the HTML after its challenge round. Mobile IPs bring nothing extra here: GETTR does not gate public content by carrier, and none of the responses changed with the type of network.

We did not test datacenter exits in this run, so we will not claim they work. Imperva scores IP reputation, and the HTML challenge on residential addresses suggests datacenter ranges will see more of it. The API endpoints look like a better candidate for cheaper exits, but test a few hundred requests before you commit to them.

Static ISP addresses are for one case only: a team that logs into its own brand account from a browser and wants the same address every session. Use ../../isp-proxies/ for that, one account per address, and nothing more.

Job	Proxy type	Why
Public profiles and posts via JSON	Rotating residential	Passed first attempt from US and Brazil
Public HTML (SEO checks, snippets)	Rotating residential	Imperva challenge, cleared on retry
Your own brand account in a browser	Static ISP, one per account	Same address every session
Geo-checking what a country sees	Residential with country targeting	Only the page language changes, see below

What changes by country

Very little, and almost all of it is language. Without JavaScript the profile title came back as "GETTR Official on GETTR - Profile and Posts on GETTR" from the US, "auf GETTR - Profil und Posts" from Germany and "no GETTR - Perfil e Posts" from Brazil. The Brazilian response was cached under the key lang:pt_br. The rendered title was English from all three countries. The response varies on Accept-Language, so the language follows the request headers as much as the exit country.

The data itself did not change. The twenty-post JSON was 60,273 bytes from the US and from Brazil. GETTR does not show different posts or counters by country, so you do not need country targeting to collect it. You need it only to check how the localized HTML and its metadata look to a Brazilian or German visitor, for example for an SEO or brand check.

One rendered run from Brazil returned only 122 words against 313 from the US for the same profile. The posts had not finished loading within the render window. If you render from distant exits, wait for a post selector rather than a fixed time.

Rate limits and the errors you will see

GETTR publishes no rate limits for its API, and we did not stress-test it. Here is what the responses and files do tell you:

• Incapsula challenge on the HTML. It is a 200 response that contains a JavaScript challenge instead of the page. Treat a response without the profile title as a block, not as content, and retry from a new exit. In our run the third attempt passed both times.
• Same bytes for five minutes. max-age=300 on the profile HTML means anything faster than one fetch per five minutes per profile and language is wasted traffic.
• 404 with JSON from the API. api.gettr.com returns JSON errors such as {"url":"/robots.txt not found"}. A missing user or a wrong path looks like that, not like an HTML error page.
• Crawl-delay 1. gettr.com/robots.txt allows everything for all user agents, asks for a crawl delay of one second, and disallows /api/, /admin/, /private/, /settings/ and /auth/ on the main domain. api.gettr.com has no robots.txt at all.

The polite reading is: one request per second per client, no logged-in paths, and no bulk enumeration of post IDs. The arXiv team walked post IDs from 1 to 10 million to find missing posts; that is the kind of volume GETTR's crawl delay asks you not to generate.

What it costs

Take a typical brand-safety or research job: watch 1,000 public GETTR accounts once a day and keep their latest twenty posts plus the profile counters. With the JSON endpoints that is about 61.3 KB per account (60,273 + 1,029 bytes), or 61 MB a day and about 1.84 GB a month. At $0.80/GB on ../../residential-proxies/ Basic, that is roughly $1.47 a month in traffic.

The same job through a headless browser is 3.81 MB per profile, or 3.81 GB a day and about 114 GB a month: roughly $91.50 at the same rate, plus about 2.7 hours of browser time a day at 9.6 seconds per page. Reading the JSON instead of rendering the page costs about 62 times less traffic.

Method, 1,000 accounts daily, 30 days	Traffic	At $0.80/GB
Profile + posts JSON	about 1.84 GB	about $1.47
HTML without JavaScript (metadata only, no posts)	about 0.26 GB	about $0.21
Rendered profile	about 114 GB	about $91.50

Byte counts are the decompressed response bodies, so traffic on the wire will be lower. Failed attempts count too: the two Imperva challenges per HTML profile roughly triple the HTML line. We do not have a ready-made GETTR collector. If you would rather not run your own retry loop, our ../../web-scraping-api/ fetches any public URL, plain or rendered, and you pay only for successful responses. It is also available as tools in Claude or Cursor through the ../../mcp-server/.

The rules GETTR sets, and what we will not help with

GETTR's terms page did not show its text to a client without a session: the page we fetched contained only the help navigation. Read the current Terms of Use in a browser before you automate anything. A 2024 legal study cites a version dated 17 May 2023. What GETTR does publish openly is the robots.txt above: the public site is open to crawlers with a one-second delay, and the main domain's /api/ path is disallowed.

The legitimate work on GETTR is clear: public-post research, brand-safety checks on where a brand's name or ads appear, social listening on public accounts, and SEO checks of how your own profile is indexed. We will not write instructions for mass account creation, follower or like automation, getting around a suspension, or collecting data that sits behind a login. A proxy does not make any of those acceptable, and it does not bring back a suspended account. For networks with a similar audience and measurements of their own, see our posts on ../truth-social-proxies/ and ../rumble-proxies/.