{"id":7590,"date":"2026-08-08T21:00:00","date_gmt":"2026-08-08T21:00:00","guid":{"rendered":"https:\/\/cybrancee.com\/blog\/?p=7590"},"modified":"2026-08-08T20:24:32","modified_gmt":"2026-08-08T20:24:32","slug":"discord-webhooks-explained-what-they-can-and-cant-do","status":"publish","type":"post","link":"https:\/\/cybrancee.com\/blog\/discord-webhooks-explained-what-they-can-and-cant-do\/","title":{"rendered":"Discord Webhooks Explained: What They Can and Can’t Do"},"content":{"rendered":"\n

Ask in almost any Discord dev server how to post automated messages into a channel, and someone will say “just use a webhook” before you’ve even finished typing the question. Then, a few messages later, someone else will mention bots, intents, and slash commands, and suddenly it’s not clear if those two answers were even about the same thing.<\/p>\n\n\n\n

They’re not, not really. A webhook and a bot can both drop a message into a channel, and that’s about where the overlap ends. One is a static URL you can POST to from a script and forget about. The other is a persistent application with its own token, permissions, and an actual connection to Discord’s servers. Mixing them up is the single most common source of confusion for anyone setting up their first server integration, and it’s usually why people end up building a whole bot just to post a build notification that a five-line webhook script would have handled fine.<\/p>\n\n\n\n

This one’s about webhooks specifically: what they are, how Discord implemented them, where they stop being useful, and how to actually wire one up.<\/p>\n\n\n\n

<\/td>Discord Bot<\/strong><\/td>Discord Webhook<\/strong><\/td><\/tr>
Authentication<\/td>Bot token + OAuth2 scopes<\/td>Webhook ID + token in the URL<\/td><\/tr>
Connection type<\/td>Persistent Gateway (WebSocket)<\/td>None \u2014 one-shot HTTP POST<\/td><\/tr>
Setup effort<\/td>Register app, invite to server, host it<\/td>Generate URL in server settings<\/td><\/tr>
Permissions to create\/manage<\/td>Granted on invite (varies by scope)<\/td>MANAGE_WEBHOOKS + VIEW_CHANNEL<\/td><\/tr>
Permission to send a message<\/td>N\/A \u2014 just needs to be in the channel<\/td>None \u2014 knowing the URL is enough<\/td><\/tr>
Reading messages<\/td>Yes<\/td>No<\/td><\/tr>
Reacting to messages<\/td>Yes<\/td>No<\/td><\/tr>
Responding to slash commands<\/td>Yes<\/td>No<\/td><\/tr>
Embeds per message<\/td>1<\/td>Up to 10<\/td><\/tr>
Attachments\/files<\/td>Yes, up to 10 MiB (more with boosts)<\/td>Yes, up to 10 MiB (more with boosts)<\/td><\/tr>
Custom username\/avatar per message<\/td>No \u2014 fixed unless code changes it<\/td>Yes<\/td><\/tr>
Presence status (online\/idle\/dnd)<\/td>Yes<\/td>No<\/td><\/tr>
Interactive components (buttons, selects)<\/td>Yes, full support<\/td>Non-interactive only, unless app-owned + with_components=true<\/td><\/tr>
DMs to users<\/td>Yes, if allowed<\/td>No<\/td><\/tr>
Posting in threads<\/td>Yes<\/td>Yes, via thread_id or thread_name<\/td><\/tr>
Cross-post to announcement followers<\/td>Yes<\/td>Yes, if the webhook is in a news channel<\/td><\/tr>
Editing\/deleting its own messages<\/td>Yes<\/td>Yes<\/td><\/tr>
Rate limit<\/td>~50 requests\/sec per bot token<\/td>~30 msgs\/min per webhook, ~5 req\/5s shared per channel<\/td><\/tr>
Needs hosting<\/td>Yes \u2014 must stay running<\/td>No \u2014 Discord hosts the endpoint<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

What Is a Webhook<\/strong><\/h2>\n\n\n\n
\"discord<\/figure>\n\n\n\n

The general concept isn’t Discord’s invention. A webhook, in the broadest sense, is just a URL that a service calls automatically when something happens, instead of you having to keep asking “did anything happen yet?” The term itself goes back to 2007, coined by developer Jeff Lindsay, and it caught on because polling an API every few seconds is wasteful when the API can just tell you the moment something changes.<\/p>\n\n\n\n

Discord’s version of this is narrower and, honestly, simpler than the general concept. An incoming webhook in Discord is an HTTP endpoint tied to one specific channel. You send it a JSON payload, Discord turns that payload into a message in that channel, and that’s the entire interaction. No login, no persistent connection, no bot application sitting in the background. Discord doesn’t publish an exact date for when this feature landed, but it’s been part of the platform for years now, well before slash commands or even threads existed.<\/p>\n\n\n\n

There are technically three webhook types on Discord, though you’ll only ever create one of them yourself:<\/p>\n\n\n\n

    \n
  • Incoming webhooks:<\/strong> the standard kind, created through server settings or the API, used for exactly what this article covers.<\/li>\n\n\n\n
  • Channel Follower webhooks:<\/strong> internal ones Discord creates automatically when you follow an announcement channel into another server. You don’t set these up manually.<\/li>\n\n\n\n
  • Application webhooks:<\/strong> short-lived, tied to a specific interaction (like a slash command follow-up), and gone once that interaction’s lifecycle ends.<\/li>\n<\/ul>\n\n\n\n

    The feature has picked up a handful of real changes over the years instead of sitting frozen:<\/p>\n\n\n\n

      \n
    • November 2020:<\/strong> webhooks gained the ability to edit and delete messages they’d already sent, instead of only ever posting new ones.<\/li>\n\n\n\n
    • August 2022:<\/strong> Discord started requiring VIEW_CHANNEL<\/code> alongside MANAGE_WEBHOOKS<\/code> to create or manage a webhook, closing a permissions gap.<\/li>\n\n\n\n
    • October 2024:<\/strong> Discord added outgoing Webhook Events, a separate system where Discord calls your<\/em> app when something happens (like a user authorizing it). Don’t confuse this with the incoming webhooks this article is about; they’re related in name only.<\/li>\n\n\n\n
    • January 2025:<\/strong> the file upload cap dropped from 25 MiB to 10 MiB platform-wide. Oddly, the change hit regular users and bots first, and webhooks weren’t folded into the new limit until slightly after the initial announcement.<\/li>\n\n\n\n
    • April 2025:<\/strong> Components V2 shipped, letting messages be built out of stacked layout pieces (containers, sections, media galleries, separators) instead of the old fixed content-then-embed-then-buttons structure. Webhooks got access to it too, with some caveats covered below.<\/li>\n<\/ul>\n\n\n\n

      Webhooks vs. Discord Bots<\/strong><\/h2>\n\n\n\n
      \"webhook<\/figure>\n\n\n\n

      The one-sentence version: bots can read and write, webhooks can only write. Everything else follows from that.<\/p>\n\n\n\n

      Setup.<\/strong> A bot needs an application registered in Discord’s developer portal, a bot token, and an actual invite into the server with whatever permissions it needs. A webhook is a URL. You generate it in Server Settings \u2192 Integrations, or through the API, and it’s ready.<\/p>\n\n\n\n

      Permissions.<\/strong> Creating or managing a webhook needs MANAGE_WEBHOOKS<\/code> on the channel (plus VIEW_CHANNEL<\/code>, since 2022). Once it exists, though, sending<\/em> through it needs nothing beyond knowing the URL. Discord doesn’t check who’s making the request, just whether the token in the URL is valid.<\/p>\n\n\n\n

      Capabilities.<\/strong> This is the real dividing line. Bots connect to Discord’s Gateway and get a live stream of events: messages, reactions, member joins, voice state changes, all of it. Webhooks get none of that. They can’t read a channel’s history, can’t react to anything, can’t respond to a slash command, and have no presence status. They exist purely to push messages outward.<\/p>\n\n\n\n

      Message features.<\/strong> Webhooks actually win a couple of these. They support up to 10 embeds in a single message versus a bot’s 1, and every message can carry its own custom username and avatar, so one webhook can look like five different “posters” depending on what you set in each request. A bot’s identity is fixed unless you’re editing its profile through code, which is a much bigger hammer for a small problem.<\/p>\n\n\n\n

      Rate limits.<\/strong> Bots get roughly 50 requests per second tied to their token. Webhooks don’t have a token in that sense, so Discord limits them more like anonymous traffic: something in the neighborhood of 30 messages a minute per webhook, a shared ceiling of around 5 requests every 5 seconds if multiple webhooks are hammering the same channel, and a hard global cap of 50 requests per second per IP address at the edge layer. Discord’s own docs are explicit that none of these numbers should be hardcoded. Read the rate limit headers on each response and back off when they tell you to.<\/p>\n\n\n\n

      Hosting.<\/strong> A bot has to run somewhere, all the time, or it goes offline. A webhook doesn’t run anywhere. Discord hosts the endpoint; you just call it when you have something to say.<\/p>\n\n\n\n

      What They Can (and Can’t) Do<\/strong><\/h2>\n\n\n\n

      What webhooks can do<\/strong><\/h4>\n\n\n\n
        \n
      • Send plain text messages, up to 2,000 characters, same as any normal message.<\/li>\n\n\n\n
      • Attach up to 10 rich embeds per message, each with its own title, description, fields, and images.<\/li>\n\n\n\n
      • Upload files up to 10 MiB (more if the server has boosts pushing the shared cap higher).<\/li>\n\n\n\n
      • Override the posting name and avatar on a per-message basis.<\/li>\n\n\n\n
      • Control which mentions actually ping people through allowed_mentions<\/code>, so a message can say “@everyone” as plain text without waking the whole server.<\/li>\n\n\n\n
      • Post into threads, and even spin up a new thread automatically in a forum channel by passing a thread_name<\/code>.<\/li>\n\n\n\n
      • Send non-interactive components like link buttons by default, and full Components V2 layouts if the webhook is application-owned, and the request includes with_components=true<\/code>.<\/li>\n\n\n\n
      • Accept Slack- and GitHub-formatted payloads directly, by appending \/slack<\/code> or \/github<\/code> to the webhook URL. Genuinely handy if a service already speaks one of those formats natively.<\/li>\n\n\n\n
      • Edit or delete messages it previously sent, through the same webhook URL.<\/li>\n\n\n\n
      • Crosspost into an announcement channel’s followers, if the webhook lives in a news channel.<\/li>\n<\/ul>\n\n\n\n

        What webhooks can’t do<\/strong><\/h4>\n\n\n\n
          \n
        • Read anything. No message history, no channel contents, nothing incoming at all.<\/li>\n\n\n\n
        • React to messages, respond to slash commands, or handle button clicks and menu selections.<\/li>\n\n\n\n
        • Show a presence status or behave like an actual user in any sense.<\/li>\n\n\n\n
        • Send or receive DMs.<\/li>\n\n\n\n
        • Use interactive, custom-ID components unless the webhook is application-owned. A plain webhook created through server settings is stuck with static, link-only buttons.<\/li>\n\n\n\n
        • Modify or delete anyone else’s messages, only its own.<\/li>\n\n\n\n
        • Do anything outside the one channel it was created for.<\/li>\n<\/ul>\n\n\n\n

          If a project needs two-way logic of any kind, a webhook alone won’t get there. That’s not a limitation to work around; it’s just outside the scope of what the feature is.<\/p>\n\n\n\n

          How to Use Them<\/strong><\/h2>\n\n\n\n
          \"kali<\/figure>\n\n\n\n

          Setting one up doesn’t require touching code at all if all you want is to test it.<\/p>\n\n\n\n

            \n
          1. Open your server and go to Server Settings \u2192 Integrations \u2192 Webhooks<\/strong>, or click the gear next to a specific channel and pick Create Webhook<\/strong> from there.<\/li>\n\n\n\n
          2. Give it a name and pick the channel it should post to. A server can hold up to 10 webhooks.<\/li>\n\n\n\n
          3. Copy the URL. It’ll look like https:\/\/discord.com\/api\/webhooks\/WEBHOOK_ID\/WEBHOOK_TOKEN. Treat it like a password. Anyone who has it can post into that channel.<\/li>\n<\/ol>\n\n\n\n

            From there, sending a message is one HTTP request<\/code>:<\/p>\n\n\n\n

            Bash<\/span>