Discord is the one large social platform whose public data is cheaper to read through the front door than through a browser, and we can put a number on it. On 28 September 2026 we fetched one public server twenty times through residential exits in the United States, Germany and Brazil. The invite page is a 9-word shell over plain HTTP and a 4,939,296-byte shell when rendered. The invite API answers the same question with no token in 2,810 bytes, byte-identical from all three countries: 305,193 members, 70,989 online, verification level 3, 54 boosts. Everything else on this page follows from that ratio.
Search for Discord proxies and you get three questions, one of them about data
The autocomplete for this term is not about Discord at all. Eleven of the fifteen suggestions are the Discord servers of sneaker-proxy vendors, the places where people buy IPs for checkout bots and trade in resale communities. Two more are about reaching Discord from a network that does not allow it. The last two, "discord webhook proxies" and "discord bot proxies", are the ones this article answers: what does discord.com hand a client that arrives through a proxy, and which surfaces are worth the bytes.
The first page of results is a vendor use-case page, two Discord server listings, a Reddit thread about corporate networks, a YouTube tutorial and an analyst listicle. The listicle is the best of them and it makes a correct technical point: Discord Web needs HTTPS, the message gateway needs a WebSocket, voice needs UDP. It still never fetches a Discord URL and counts what comes back, so we did.
Our subject is one public, verified, discoverable server, Discord Developers, chosen because it is the community Discord runs for people building on its API. The same three surfaces exist for every server that publishes an invite or opts into Server Discovery.
The invite page is a shell, and the render makes it a bigger shell
We audited discord.com/invite/discord-developers with and without JavaScript from each of the three exits. The three countries returned the same thing.
| Fetch | Exit | Bytes | Extractable words | Title |
|---|---|---|---|---|
| Invite page, no JavaScript | US | 24,486 | 9 | Discord Developers |
| Invite page, no JavaScript | DE | 24,486 | 9 | Discord Developers |
| Invite page, no JavaScript | BR | 24,486 | 9 | Discord Developers |
| Invite page, rendered | US | 4,939,296 | 19 | Discord |
| Discovery page, no JavaScript | US | 79,461 | 476 | Discord Developers - Official Discord Server |
| Invite API, no token | US / DE / BR | 2,810 | full JSON object | n/a |
Read the rendered row first, because it is the one that empties budgets. The browser pulled 4,939,296 bytes of application, ran for 14.5 seconds, and produced 19 words, ten more than the plain fetch. The title got worse: the server-rendered head says "Discord Developers", the hydrated app replaces it with "Discord". Rendering an invite page is 1,758 times the bytes of the API call for less information than the API call. Skip it.
The plain fetch is not useless, and the reason is a single line in the head. The meta description of every invite page ends with the member count:
<meta property="og:description"
content="Welcome to Discord Developers (DDevs), the official home for
the community of developers building apps, bots, games, and more
with Discord APIs. | 305193 m">That trailing "305193 m" is the member count followed by a word Discord's own description length cut in half. If all you need is a headcount per invite link, it is in 24,486 bytes of plain HTML with no JavaScript. But there is a better route, and it costs one tenth of that.
The invite API answers a client with no token, in 2,810 bytes
Discord's HTTP API is documented as a bot API, and almost all of it wants an Authorization header. The invite resource is the exception. GET /api/v10/invites/<code>?with_counts=true returned 200 with a 2,810-byte JSON object to a client that sent no token, no cookie and no session, from all three exits, in 0.7 to 6.4 seconds depending on the exit.
curl -x http://USER-country-us:PASS@pr.quanticdata.io:7777 \
"https://discord.com/api/v10/invites/discord-developers?with_counts=true" \
-D - -o invite.json
# approximate_member_count: 305193
# approximate_presence_count: 70989
# guild.verification_level: 3, premium_tier: 3, premium_subscription_count: 54
# guild.features: VERIFIED, COMMUNITY, DISCOVERABLE, ... (55 flags)
# profile.tag: CODE, channel.name: rules, expires_at: nullFour things in that object matter for a data job. The counts are labelled approximate and they are live: the member count read 305,193 on our first fetch and 305,197 on the last, forty minutes later. The features array is where the server describes itself, 55 flags on this one, including DISCOVERABLE and VERIFIED, which is how you filter a list of invite codes down to the servers that opted into being found. verification_level and premium_tier are the fields a community-research dataset actually wants and the HTML never renders. And expires_at tells you whether the invite is permanent, which for a vanity URL like this one it is.
The response carries cache-control: public, max-age=300, so the counts are at most five minutes stale and repeated fetches inside that window are answered from the edge. The German fetch also returned the rate-limit headers Discord documents: x-ratelimit-limit: 50, x-ratelimit-remaining: 49, a bucket id, and a reset in 0.1 seconds. The documentation states the global figure plainly: 50 requests per second, and when no Authorization header is present that limit is applied to the IP address. That sentence is the whole reason a proxy pool belongs in front of a Discord collector: the ceiling is per address, so throughput is the number of addresses you have, and nothing else.
The rule the documentation adds is worth obeying to the letter: addresses that make too many requests Discord classifies as invalid are cut off for a period, and the documented threshold is 10,000 such requests in 10 minutes. A collector that hammers expired invite codes or endpoints that need a token is manufacturing exactly those. Validate codes against the invite endpoint, back off on the reset header, and rotate on volume, not on errors. Our note on rate-limit replies while scraping covers the backoff arithmetic.
Server Discovery pages render server-side, 476 words in 79 KB
The invite page is a shell because it is the web app. The discovery page is not. discord.com/servers/discord-developers-613425648685547541 returned 79,461 bytes and 476 extractable words to a plain HTTP client, with a canonical link, a real title, the server description, category, upcoming events and member figures rendered in the HTML. It is one of the surfaces robots.txt points search engines at: the file lists seven sitemaps, and the first two are the server discovery index and its parent search index.
That is the public directory. It only lists servers whose owners turned on Server Discovery, and Discord's Terms of Service say so directly: server owners and admins control whether their server is available in Discovery and whether the invite link is published on public websites. Both routes in this article read only what an owner chose to publish, which is the line that keeps a community-research project on the right side of the platform.
The widget is the third surface people ask about, and it is opt-in too. /api/guilds/<id>/widget.json answers with channel and presence data only for servers that enabled the widget; this one has not, and Discord says so with its own error code 50004, "Widget Disabled". Treat that reply as a fact about the server, not about your address.
The exit country changed nothing, which is itself the finding
On Facebook a German exit rewrites the follower count into German number format. On TikTok it selects a different backend. On Discord we fetched the same invite page and the same API call from the United States, Germany and Brazil, and got the same 9 words, the same description, and the same 2,810 bytes with the same field values. Discord localises the application after it loads, in the browser, from the account's language setting, not from the IP.
For a data job that means geo targeting buys nothing on the public surfaces, and you should not pay for it. What the exit country does still decide is where your requests are counted: the 50-per-second ceiling is per address, so a pool spread across countries is simply a bigger pool. Pick the cheapest exits that answer, and pin a country only when you are checking how a Discord ad or a server listing is served in a market.
What robots.txt allows, and what the Developer Policy forbids
discord.com/robots.txt is 1,774 bytes and unusually specific about the API. For every client it allows /invite, /api/v*/invite, /api/v*/discovery, /api/v*/applications, /terms and /privacy, then disallows /channels, /api as a whole, /widget, /profile/, /oauth2 and the account-recovery paths. The two routes measured above are exactly the two the file permits. It names no AI crawler at all; the only named agents are Twitterbot, with the same rules, and a block that reads "User-agent: nsa / Disallow: /".
The Developer Policy is where the limit sits. Rule 20 says, in full: "Do not mine or scrape any data, content, or information available on or through Discord services." Rule 13 forbids inflating server membership with bot or user accounts and automating messages to keep a server looking active. The Terms of Service add that your content is yours but licensed to Discord, and that automated access is governed by the developer terms. So the honest framing is this: the invite and discovery endpoints publish what server owners chose to make public, robots.txt explicitly permits reading them, and the Developer Policy still says that mining Discord data as an application developer is out. Read the public directory for research, verification and moderation tooling; do not build a product that harvests Discord. Where you stand on that line is your call, and it should be made after reading rule 20, not after reading a proxy vendor.
Messages are a separate matter and this article does not touch them. Reading channel history requires a bot the server owner installed, with the permissions that owner granted. Running a user account as a bot, a so-called self-bot, breaches the Terms, and no proxy changes that.
What each Discord 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 |
|---|---|---|---|
| Invite API with counts, no token | 2,810 | 355,872 | $0.0000022 |
| Discovery page, no JavaScript | 79,461 | 12,585 | $0.000064 |
| Invite page, no JavaScript (count in the head) | 24,486 | 40,840 | $0.000020 |
| Invite page, rendered | 4,939,296 | 202 | $0.0040 |
A gigabyte of residential bandwidth holds 355,872 invite objects. A hundred thousand invite codes checked daily for a month is 8.4 GB, about $6.75, and the constraint is not bandwidth but the 50-per-second ceiling per address: at that rate one address clears 100,000 codes in 33 minutes, so the pool size is set by how fast you want the answer, not by cost. The same job through the rendered page is 494 GB and $395 for less data. There is no version of a Discord workload where rendering the invite page is the right call, and we would rather say that than sell the bandwidth.
The setting that works on Discord
- Network: residential proxies, Basic line, $0.80/GB, rotating. Twenty fetches from three countries met no address-level obstacle on the invite API or the discovery pages; the per-address ceiling of 50 requests per second is the only reason to hold more than one exit. Mobile at $2.30/GB and ISP at $2.50/IP per month bought nothing we could measure.
- Fetch mode:
engine: tls, plain HTTP, never rendered. The invite API returns the complete object in 2,810 bytes; the discovery page returns 476 words in 79,461 bytes; the rendered invite page returns 19 words for 4,939,296 bytes. - Country: none required. The API returned identical 2,810-byte bodies from the United States, Germany and Brazil and the HTML returned the same 9 words; spread the pool across countries for throughput, and pin one only for ad or listing verification in that market.
- When the proxy is not enough: there is no Discord collector in our catalogue, and the invite endpoint does not need one. For the discovery pages, the web scraping API without rendering returns the page as clean Markdown from $0.0002 per page, retries and rotation included, and failed requests are never billed. If you want the same measurement on your own list of invite links, the SEO Audit API fetches each one with and without JavaScript for $0.0012 per URL.
- Free tier: every account gets $2 of free API usage per month, which is 10,000 discovery pages through the scraping API before you pay anything.
Read invites through the API, read the directory over plain HTTP, hold enough addresses for the rate you need, and stay out of channels you were not invited to. That is the whole configuration. For the two platforms in this series where the answer was also "use the public API", see Bluesky and Mastodon; for the one where the web preview is the API, see Telegram.