How Do You Export Discord Message History for Feedback Analysis Without Hitting Rate Limits?
Nothing stops you from pulling a year of Discord messages in one clean sweep, except that Discord's API wasn't built to hand a year of messages over in one clean sweep. There are two ways to get message history out: the Get Channel Messages endpoint, which paginates through a channel's full history 100 messages at a time using message IDs as a cursor, and Search Guild Messages, which caps at 25 results per request, stops accepting new pages past an offset of 9,975, and can return a 202 "not indexed yet" response for content nobody has touched in a while. Pick the wrong one, or paginate the right one carelessly, and a feedback-analysis pull turns into a multi-day project of babysitting 429s.
For a bulk export, use Get Channel Messages instead of search, because search was built to answer "find that one message," not "give me everything." Channel history has no offset ceiling because it doesn't use offsets. It walks backward from the newest message using the before parameter, which means the only real constraint is Discord's global rate limit of 50 requests per second for bots, plus per-route limits on top of that. A patient, correctly-paginated script clears that limit fine. The parts that actually derail people are the two things nobody warns you about going in: message content requires a privileged intent your bot might not have, and Discord will throttle you exactly the way its documentation says it will, with no grace period for someone who didn't read it first.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe intent you need before any of this works
Before pagination or rate limits matter at all, there's a permissions problem. MESSAGE_CONTENT is a privileged Discord intent, and per Discord's gateway documentation, it gates message content across both the Gateway and the REST API. As the docs put it: "HTTP API restrictions are independent of Gateway restrictions." Without it, a bot's Get Channel Messages calls succeed, return message objects, and every content field comes back empty. The bot still sees who posted and when; it just can't see what they said, which is the one thing a feedback pull needs. If your bot already sits in 100 or more servers, MESSAGE_CONTENT also requires Discord to verify the app and separately approve the intent from the developer portal, a step that isn't instant.
This is the failure mode that eats the most time, because it doesn't look like an error. The request returns 200, the JSON looks right, and the content key is just an empty string. Nothing in the response tells you the intent is missing.
The numbers that actually throttle a pull
Once the intent is sorted, three limits shape how a bulk export behaves:
- 100 messages per request on Get Channel Messages, paginated backward with the
beforeparameter using the oldest message ID from the previous page as the next cursor. - 50 requests per second globally for the bot's whole application, per Discord's rate limit docs, tracked via
X-RateLimit-RemainingandX-RateLimit-Reset-Afterresponse headers, with a 429 and aretry_afterfield if you go over. - 25 results per request on Search Guild Messages, with pagination stopping at a 9,975 offset and a 202 response with its own
retry_afterfor messages that haven't been indexed recently. Discord's own docs note search "may return slightly fewer results than the limit specified" for old content and warn against relying on page length to drive pagination.
None of these three numbers is the actual bottleneck for a well-written script pulling one channel's history. The bottleneck is treating search like an export tool, because its 25-per-request cap and hard offset ceiling mean a channel with more than roughly ten thousand searchable messages simply cannot be walked end to end through search, no matter how patient the script is.
Callum Brix hits the offset wall
Callum Brix runs community support at Palfrey, a small API-monitoring tool with an active Discord server where customers report bugs and ask for features. In November, a founder asked him for every message mentioning "webhook" from the past year, wanting to know whether webhook reliability complaints were actually climbing or just felt louder lately.
His first attempt used the search endpoint with content=webhook, paging through 25 results at a time. It worked cleanly for a few thousand messages, then the offset climbed toward the 9,975 ceiling and the script started returning a 400 instead of a page of results, two-thirds of the way through a fourteen-month channel. Not a rate limit, not a timeout: search simply stops accepting new offsets past that point, and no parameter raises the ceiling.
Switching to Get Channel Messages fixed the offset problem but introduced two more. Without retry-after handling built in, the pull needed three separate runs across two days to clear a 429. And once it finished, the CSV had no message content for the two months Callum had spent waiting on Discord to approve MESSAGE_CONTENT for the bot. The export ran fine; it just couldn't see what people said during that stretch. "I found out the intent was still pending by staring at a column of empty strings," he said.
DiscordChatExporter helps, but it's still an export
For a one-off pull, DiscordChatExporter is the tool most teams reach for rather than hand-rolling pagination. It's open source, exports a channel to JSON, CSV, HTML, or plain text, and handles the rate-limit backoff and cursor pagination internally. It authenticates with either a bot token or a user token, though the project's own documentation warns that automating a personal account violates Discord's terms of service and risks suspension. A bot token is the only supportable path for anything recurring.
That covers the mechanical part. It doesn't solve the intent problem above (the bot token still needs MESSAGE_CONTENT), and it doesn't solve the bigger issue, which is that every run is a fresh snapshot. Nothing produced today knows about a message posted five minutes from now.
The scheduled pull breaks down at three points
A scheduled export job is fine for an occasional audit. It breaks down once any of these show up:
- Someone needs "is this trending" rather than "what happened last year." A weekly cron job answers questions about the past; it can't tell you a complaint spiked yesterday.
- The same bug gets reported across channels, and nobody's deduping the export. A CSV with 40 rows mentioning "webhook" isn't 40 distinct problems, and figuring out how many it actually is means reading all 40 by hand.
- Requesters need to be told when something ships. An export is a flat file. It doesn't remember that Callum promised the founder an answer, or which of the 40 messages came from a paying account versus a lurker asking out of curiosity.
That's the point where continuous capture beats scheduled export, and it's the category Modem works in. Modem's Discord integration subscribes to the channels you choose and classifies messages into topics as they're posted, so there's no job to schedule, no offset ceiling to hit, and no gap between "the founder asked" and "the answer is current." Reports about the same bug across channels dedupe into one counted topic instead of one row per mention, with every reporter still attached to it. Modem is what we build, so that recommendation is worth naming plainly rather than taking on faith: a scheduled export is still the right call for a one-time pull like Callum's, and it stops being the right foundation the moment the question becomes an ongoing one.
If webhook complaints are a live question rather than a one-time report, the two guides worth reading next are why Discord search fails to find old feature requests and how to export Microsoft Teams chat history for feedback analysis, for teams running the same problem across both platforms at once.
