Seven Years, Three Rejections, and Counting: The Discord Privileged Intent Saga

I built a Discord bot called SkyBotZ in November 2019. It manages a Minecraft Hypixel SkyBlock community - currently 190,000+ members, and it's been well above Discord's 10,000-user threshold for privileged intent review for years. The bot handles account verification, nickname enforcement, role assignment, a reputation system for in-game services, scammer detection, staff moderation tools, and a web admin panel. I've maintained it for nearly seven years as an unpaid volunteer. On June 11, 2026, Discord sent me an email.

What followed is a masterclass in corporate bureaucracy defeating volunteer infrastructure.

June 11: The Email

The email arrives at 19:11 UTC. "SkyBotZ has crossed 10,000 users" (It serves one server with 190,000+ members - it's been well above their threshold for years, which they have arbitrarily started enforcing). It's access to "privileged intents" - specifically Guild Members and Message Content - now requires review. I have 90 days to submit a request. If I don't, the intents are removed and core functionality breaks.

The email is friendly in the way corporate emails are friendly - "We're here to help make this process smooth!" - but the deadline is real. September 9, 2026. Or so I think. What I don't know yet is that each rejection resets the clock to 30 days from the rejection date, so my diligence in responding quickly has been quietly shortening my runway. By the time the third rejection lands, the deadline will have moved from September 9 to August 19.

I submit the same day. The form asks what the bot does, why it needs each intent, whether data is stored off-platform, whether users can opt out. I answer honestly. The Guild Members intent is load-bearing - verification, nickname enforcement, role assignment, permission checks, member join handling. The Message Content intent is needed for - critically - reading messages from other bots to validate reputation entries, staff command logging, and legacy prefix commands.

I get a confirmation email. Request #66210938. "If your app has Privileged Intent access now, it will retain that access while your submission is under review."

I assume this is a formality. The bot has been running for seven years. The use cases are obvious.

July 8: The First Rejection (Nearly a Month Later)

Don Jinwoo sends the response. The request "could not be processed due to an issue with the submission itself." The issue: the privacy policy. It should be "hosted at a stable, permanent URL and describe your data practices - not a Discord server link, a link to Discord's own privacy policy, or otherwise inaccessible link".

I go back to the form. The privacy policy question is a simple yes/no: "Do you have a public Privacy Policy telling your users about their data usage?" No is a valid option. There's no verbiage indicating it's required, no asterisk, no warning. I chose "no" because I didn't have one. The form accepted it. But my request was rejected for not having one.

I don't have a privacy policy. I'm one person maintaining infrastructure for a community I care about. The bot stores Discord snowflake IDs (user IDs, role IDs, channel IDs) as foreign keys in PostgreSQL. It does not store usernames, avatars, nicknames, or emails. The only message content that touches external storage is application logs streamed to Grafana Loki with a 14-day retention policy. There is nothing to be private about. But Discord has decided I need a privacy policy, so I write one.

I deploy it the same day. It's a real privacy policy - covers what data is collected, what isn't, third-party services, encryption, data deletion requests, the whole thing. I add a link to it in the web admin panel's navigation drawer. I update the bot's application description in the Developer Portal to include the link. I do everything a reasonable person could do.

When I go to resubmit, I discover the form has been wiped clean. No reference to my previous submission, no pre-filled fields, no "edit your existing request" option. Just a blank form. There is no "save draft" and no "review previous submission." The rejection email doesn't include a copy of what you submitted. For a form that requires detailed technical justification across multiple 2,000-character fields, this is downright hostile.

Before I resubmit, I send a reply to Don Jinwoo's email. The date is July 8, 2026, at 11:58 PDT:

Y'all marked the privacy policy is optional but now you're blocking (or seem to be) on that and now you don't even give me enough context so I have to start from scratch on a fucking resubmission? Can you give me a reference of everything I submitted already.

Also can you give me some clear and concise guidance instead of this... Lacking response? By the sound of it you didn't even look at it. Y'all literally just said there was an issue despite me filling it in as requested and then give me no context. We're talking about application I created for a server that I don't even care to fucking support but would be a detriment to them if they lost. The amount of motivation I have to figure out your fucking cryptic bullshit is beyond me.

This is not my best moment. But consider the position I'm in. I've been rejected for not filling out a field that the form presents as optional. When I go to resubmit, the form is blank - no reference to what I previously submitted, no copy in the rejection email, no "review your last request" option. The only reason I still have my answers is because I had the foresight to write them down in a markdown file while composing them. If I hadn't done that, I would have been utterly fucked - staring at five empty 2,000-character text boxes, expected to reconstruct from memory a detailed technical justification for a bot I wrote seven years ago. That realization, landing on top of the rejection itself, is what you hear in that email. It is not an unreasonable response to a system designed to make you fail.

July 16: Arwen's Copy-Paste

Eight days later, Arwen replies:

Your Privileged Intents request has already been processed and will not be reopened. If you've made changes to your Application and would like it reviewed again, you're welcome to submit a new request. Before submitting, we encourage you to review the following to make sure your use case requires Privileged Intents and complies with our requirements:

- Getting Started With Privileged Intent Review
- You Might Not Need a Privileged Intent
- Developer Policy
- Developer Terms of Service

Please note that we will not be able to provide you with specific details about how your request was processed or guidance on how to comply with our various terms.

"We will not be able to provide you with specific details about how your request was processed or guidance on how to comply." This is the sentence I keep coming back to. I asked for specific guidance. The response is a form letter telling me they cannot provide specific guidance. The links are to generic documentation pages. There is no human being on the other end of this conversation.

July 17: The Second Rejection

I resubmitted on July 9 with the privacy policy in place. The rejection arrives July 17 at 17:38 UTC from Nora Neko:

Based on the information provided, your requested access has not been granted. This is because your app's described use case can be achieved without the Message Content Intent. Check out our Developer Documentation guide to assess alternative implementations for your use case.

If you want to maintain the use case, consider using app command options (also known as slash commands) instead. App commands are a constantly growing surface with new options and performance improvements being made regularly, as further described in our documentation.

Keep in mind that bots can continue using @mentions, replies to app messages and DMs for user interaction, even if they don't have the Message Content Intent.

This is the rejection that breaks something in me. Not because it's a rejection - I can accept a rejection. Because the suggestion is technically illiterate.

The Technical Problem With "Just Use Slash Commands"

Here is where I need to get precise, because this is the part that matters.

Discord is suggesting I replace my Message Content intent usage with slash commands. For some use cases, this is reasonable. Prefix commands like z!verify can become /verify. DM-based verification flows work without the intent anyway. I conceded both of these points in my resubmission.

But I have four use cases that cannot be replaced by slash commands. Not because I'm lazy or because the code is old - because they are structurally impossible with slash commands. Here they are:

1. Staff Activity Tracking. My bot reads embeds posted by a third-party moderation bot in a staff log channel. It parses those embeds to extract which moderator took which action (warn, mute, ban) and builds weekly activity reports. The moderation bot is not mine. I have no control over what it posts. It autonomously generates log embeds when staff use its commands. There is no slash command that gives me access to what another bot logged. The data exists only as message embeds from a bot I don't control.

2. Reputation Validation via ServiceBot Logs. When a user submits reputation for an in-game service, my bot searches the message history of a dedicated log channel for embeds posted by a separate bot called ServiceBot. It parses those embeds - "New Request", "Request Finished", "Claimed by" - to verify that a real interaction occurred before allowing reputation. ServiceBot is a completely separate bot that manages crafting and transfer transactions. It posts embed logs of its own accord. There is no API, webhook, or slash command interaction that could provide this data. It exists only as message embeds posted by another bot.

3. Reputation Validation via Channel History. When ServiceBot logs aren't available, the bot falls back to checking whether the two users actually interacted in a shared channel within a configurable time window. It fetches recent messages and checks metadata only - who sent them, when, whether one is a reply to the other, whether one mentions the other by ID. The actual content of those messages is never saved, never analyzed for meaning, never fed to any model. The bot checks WHO talked to WHOM and WHEN. Slash commands cannot retroactively access this metadata from past user messages.

4. Staff Review of Reputation Entries. When staff review reputation submissions on the web dashboard, the system fetches the actual historical messages - by stored message ID - so reviewers can read the real conversation context. The message content is not stored in the database. Only snowflake IDs are persisted. If the content were saved, this fetch wouldn't be necessary - it exists precisely because the bot was designed to minimize data retention. Staff need to read the actual conversation at review time to determine whether a service was legitimately provided, and that content exists only in Discord's message history. This requires reading past messages that are not commands and were never directed at my bot.

July 17: My Reply

I reply at 10:52 PDT:

Can y'all please describe how exactly expect me to fucking accomplish that? How do you think this is possible? I described some cases that could be replaced with updates to code that hasn't been touched in half a decade, but I also described cases that explicitly cannot be changed due to their nature. So I'd like you to tell me exactly what you think you're suggesting, please breakdown each example to your suggested non-intent based alternative.

I am asking a direct technical question. I want them to explain, specifically, how to read another bot's message embeds without the Message Content intent. I want them to tell me how slash commands can access historical channel messages between two users. I am not being difficult. I am asking for the technical solution they claim exists.

July 20: Arwen's Second Copy-Paste

Arwen replies at 08:53 PDT with the exact same email from July 16. Word for word. The same generic links. The same "we will not be able to provide you with specific details." I check the timestamps to make sure I'm not looking at the wrong email. I am not.

The same day, at 15:53 UTC, Nora Neko sends the third rejection. It is identical to the July 17 rejection. Word for word. "Your app's described use case can be achieved without the Message Content Intent." It cannot. I have explained, in technical detail, why it cannot. Nobody has engaged with that explanation.

The Fine Print

Arwen's emails linked me to the Developer Policy and Developer Terms of Service. "We encourage you to review the following," they wrote. So I do.

In Section 12(e) of the Developer Terms, I find something. I opted out of Discord's arbitration clause in April 2024. I have the email - sent to [email protected], with my account details, my phone number, everything they asked for. I did what the process required.

The Developer Terms became effective July 8, 2024. Section 12(e) incorporates the arbitration clause from the consumer Terms of Service by reference - the same clause I opted out of - but establishes a new 30-day opt-out window specific to developer activities. "The date for emailing an opt-out notice is within 30 days of July 8, 2024 or when you first create an Application, whichever is later." My application was created in November 2019. The window was 30 days from July 8, 2024.

I didn't receive notice that the Developer Terms were adding an arbitration clause. I didn't receive notice that a new opt-out window had opened. The window closed on August 7, 2024, and I never knew it existed.

So I'm split-brain. For consumer Discord services, I opted out of arbitration. For developer access to the APIs I've been using for seven years, I'm back in - because Discord restructured the clause into a separate policy, reset the clock, and didn't tell me.

I don't know how many other developers this affects. I don't know if it's enforceable. I don't wonder whether it's hostile.

Where Things Stand

I resubmitted again at 22:18 UTC on July 20 with the same strengthened arguments. I do not expect a different outcome. Einstein's definition of insanity is doing the same thing over and over and expecting different results, but Discord's review process leaves no other option - there is no appeals process, no human contact, no way to reach someone who can actually read a technical explanation and assess whether it's correct.

The deadline is now August 19. Each rejection gives 30 days to resubmit before intents are removed. My urgency to resolve this quickly - submitting the same day, resubmitting within 12 hours of each rejection - has been compressing the timeline rather than helping. The original September 9 deadline is long gone. I'm burning through grace periods faster than Discord is burning through form letters.

Meanwhile, I'm gutting the bot. I'm talking with the SkyBlockZ team about which features to cut. The staff activity tracking - the thing that reads another bot's embeds to build moderation reports - will probably go. The channel history fallback will definitely go. But the reputation system itself can't just be turned off - it's used by tens of thousands of members who rely on it to know who's trustworthy. For the ServiceBot log validation, I'm imposing on the ServiceBot developer to build an API so I can stop reading their embeds from Discord and start fetching the data directly. That's weeks of work for two people who both maintain this infrastructure as volunteers - work I'm fitting into the margins of a 68-hour work week across two jobs. This is time I don't have, being spent to replace functionality that already works, because Discord's review process cannot distinguish between "commands directed at my bot" and "messages from other bots that my bot needs to read."

The privacy policy I wrote to satisfy their first rejection? It's still up. It accurately describes my data practices. Nobody who reviewed my submission appears to have read it. The application description in the Developer Portal, updated to include the privacy policy link as their form suggests? Still there. Nobody appears to have checked it.

I have been maintaining this infrastructure for seven years. I do not expect gratitude - I built it because the community needed it and I could build it. But I did expect, when Discord told me to justify the bot's existence, to be met with a process that could engage with technical reality. What I got instead was a form letter, a copy-paste, and another form letter. Three rejections. Two support reps who cannot provide specific guidance. One suggestion that demonstrates a fundamental misunderstanding of how their own API works.

The bot will probably survive in some reduced form. The features that genuinely require reading other bots' messages - the ones I built because no alternative existed - will not. And the community will lose functionality it has relied on for years because a review process designed to protect users is, in practice, punishing a volunteer for building infrastructure that serves them.

I build things for communities I'm in because I can see what's missing and I know how to make it. This is the first time I've been told to stop.