Every Discord API limit, in one table

Discord enforces limits at four layers and a bot has to respect all of them at once. The REST layer has a global ceiling of 50 requests per second per bot plus per-route buckets whose size is only revealed in response headers. The gateway (the WebSocket that delivers events) caps how many payloads you may send per minute, how often you may identify, and how many guilds one connection can serve before sharding is mandatory. Payload limits govern what fits in a message: 2,000 characters of content, 10 embeds, 6,000 combined embed characters, 10 attachments, 10 MiB uploads by default. And resource caps bound what a server can hold: 250 roles, 500 channels, 15 webhooks per channel, 20 distinct reactions per message.

The three REST failure modes are worth separating because they demand different responses. A route bucket 429 (scope user or shared) means one endpoint's budget is spent: wait retry_after and only that bucket's traffic must pause. The global limit (50/s, scope global) means the whole bot must pause. And the invalid request limit is the one that takes you off the air entirely: 10,000 requests returning 401, 403 or 429 within 10 minutes gets the IP temporarily banned by Cloudflare in front of the API, after which every call returns Cloudflare's HTML "error 1015" page instead of JSON until the ban lapses. Bots hit that third tier by hammering the first two: an unhandled 429 retried in a tight loop, or a dead token retried overnight, manufactures invalid requests at machine speed.

Most of these numbers are documented in different places (rate limits topic, gateway topic, message resource, application commands, components reference, and the 30xxx error codes that fire when a cap is hit). This page collects them with the official source for each row. Where Discord does not publish a figure, the row says so rather than guessing; per-route bucket sizes in particular are intentionally unpublished and must be read from X-RateLimit-Limit at runtime. When a limit is exceeded the response is either HTTP 429 with retry_after or a specific error code such as 30005; the Discord error codes directory covers those.

Discord rate limits every REST request against a global per-bot budget and a per-route bucket. Bucket sizes are not published; you learn them from the X-RateLimit-* headers on each response. Buckets are keyed by route and major parameter (channel, guild or webhook ID), and X-RateLimit-Bucket lets you recognize when two routes share one. Exceeding any limit returns HTTP 429 with retry_after (seconds, float) and a global flag telling you whether only that bucket or the whole bot must pause. Invalid requests (401, 403, 429) are counted separately: 10,000 of them in 10 minutes triggers a temporary Cloudflare ban of the IP, so an unhandled 429 in a retry loop escalates itself into a full outage.

The gateway is the WebSocket over which your bot receives events and sends a small set of commands (heartbeat, identify, presence update, voice state update, request guild members). It has its own rate limit, an identify concurrency limit, a daily session start budget, and a hard cap on guilds per connection. The consequences arrive as close codes rather than 429s: exceed the send limit and the socket closes with 4008, identify without enough shards and it closes with 4011, request a privileged intent you have not enabled and it closes with 4014. A reconnect loop that ignores those codes drains the daily identify budget and locks the bot out until the window resets.

These are the payload limits enforced on Create Message, Edit Message and Execute Webhook. Exceeding any of them returns HTTP 400 with error 50035 Invalid Form Body and an errors object pointing at the exact field, while sending a message with nothing in it at all fails with 50006. The 2,000-character content limit applies to bots regardless of the developer's Nitro status; Nitro's higher limit is a user-account feature. Webhook executions and interaction responses use the same limits, so one local validation layer covers all three send paths. Validate lengths before the request leaves your process: the API tells you what was wrong, but only after you have spent a request and logged an error.

Upload limits depend on the destination server's Boost tier, not on the bot. Discord documents a 10 MiB default and says it may be higher depending on Nitro status (users) or the server's Boost Tier. Oversize uploads fail with 40005 at the transport layer or 50045 after parsing, and a file Discord cannot decode fails with 50046 regardless of size. Image fields that take data URIs (emoji, avatars, icons) and sticker uploads have their own, much smaller caps listed below. Validate sizes and formats locally before uploading so user-supplied files fail in your code with a clear message instead of at Discord.

Application commands are registered per application (global) or per guild, with separate quotas for each command type. Names must be 1-32 characters, lowercase for CHAT_INPUT, matching the documented regex; descriptions 1-100. Registering more than the quota or breaking a name rule fails with 50035, creating too many in one day fails with 30034, and editing a command by a stale ID after a re-registration fails with 10063. Guild commands update instantly and are the right tool for development; global commands are what production bots should register, and the daily create budget is why registration belongs in a deploy script, not in startup code.

Every interaction (slash command, button, select, modal) must receive an initial response quickly; after that the interaction token allows follow-ups for a limited time. Missing the initial deadline produces 10062 Unknown interaction and the user sees "The application did not respond"; responding twice produces 40060. The deadline is measured from when Discord created the interaction, not when your handler started, so hosting latency and cold starts eat into it. Deferring first (callback type 5, or type 6 for component updates) is the standard pattern: it satisfies the 3-second rule and converts the budget into the token's full 15-minute lifetime.

Buttons, select menus and text inputs live inside action rows (or, with the IS_COMPONENTS_V2 flag, inside layout components). Exceeding a count or length produces 50035 naming the component path. All interactive components need a custom_id of 1-100 characters, unique within the message. Remember that every click or selection is itself an interaction with the same 3-second acknowledgement deadline as a slash command, so a component-heavy UI inherits the 10062 failure mode too. Action rows are the v1 container; Components v2 replaces them with layout components and raises the total component count but adds a combined text cap.

Webhooks post without a bot token and follow the same payload limits as messages. Channel capacity is capped at 15, and the 16th create fails with 30007; a deleted or mistyped webhook URL returns 10015 forever, so senders need a disable-on-404 path. Per-webhook execution buckets exist but their size is not published; read the rate limit headers on Execute Webhook responses. Webhooks can post into existing threads in any channel via the thread_id query parameter, but can only create new threads in forum and media channels; passing thread_name anywhere else fails with 220003.

AutoMod rules are configured per guild through the auto-moderation endpoints, and every field on a rule has a documented ceiling: how many rules of each trigger type a server may have, how many keywords and regex patterns one rule may carry, and how long each entry may be. Bots that manage AutoMod hit these caps with 50035 at write time; bots that merely post content collide with the rules themselves, and a matching rule blocks the message with 200000 or the thread title with 200001. Reading a server's rules (Manage Guild required) is the reliable way to explain a block to a user, so the shape of these limits matters even to bots that never write a rule.

Per-server caps, mostly enforced through 30xxx error codes when a create call would exceed them, plus the field-length rules on guild, channel and role objects and the pagination limits on list endpoints. Several of these are ones bots silently exhaust over months of automated creation: the 251st role fails with 30005, the 501st channel with 30013, the 251st pin with 30003, and by the time the error fires the cleanup job is archaeology. Monitor the counts your bot grows (roles, channels, pins, invites, webhooks) instead of discovering the ceiling from a support ticket, and give every automated create a matching delete path.