Discord's HTTP API models servers (guilds), channels (guild channels, DMs, group DMs, threads), users/members, applications (bots and OAuth2 apps), webhooks, and a handful of auxiliary resources (roles, scheduled events, entitlements, lobbies, stickers, emojis, soundboard). Most useful workflows pivot around a small set of IDs: guild_id, channel_id, message_id, user_id, application_id, webhook_id (+ webhook_token), role_id, and guild_scheduled_event_id. Understanding which ID is required where, and where to obtain it, is the key to accomplishing user requests efficiently.

How the domain is organized

Guilds are the top-level server resource for community-related operations: channels, members, roles, scheduled events, emojis, stickers, and guild-level webhooks live under a guild_id. Channels are the focal point for messaging: guild channels, private (DM) channels, group DMs, and threads share many channel-scoped endpoints and are returned as union types that indicate their concrete kind.

Applications (bots/OAuth apps) are a separate scope. Application-scoped resources include application commands, application emojis, entitlements, and role-connections; these require the application_id. Webhooks are a hybrid resource: a webhook record (by webhook_id) plus a webhook_token can be used to post without the application's bot token. Interaction responses also use interaction_id and interaction_token and are accessed through webhook-style endpoints anchored to an application.

Lobbies and matchmaking-like resources use lobby_id and have their own member/message endpoints; they are orthogonal to guild channels but follow the same pattern (list, create, edit, delete).

Entry points — where to call first to get the IDs you need

Begin by fetching the resource that naturally contains the ID you need rather than guessing names or constructing IDs. Typical first calls:

• If the user references a server name or wants to operate in a server: call list_my_guilds or get_guild to obtain guild_id and optional counts. Use list_guild_channels to map channel names → channel_id inside that guild.

• If the user wants to DM someone: call create_dm with the recipient(s) to produce a DM channel (returns a channel object with id). Use that channel_id for create_message/update_message/reactions.

• If the user asks to post as a webhook or follow up to an interaction: obtain the webhook_id/webhook_token from create_webhook (channel-scoped) or from stored webhook credentials. get_webhook_by_token can validate and return the webhook object from webhook_id + webhook_token.

• For bot/application actions (commands, entitlements, metadata): call get_application or get_my_application to confirm application_id, then list_application_commands / list_guild_application_commands as needed.

• To act on a specific message: call list_messages or get_message (requires channel_id first). Many message-based workflows require both channel_id and message_id.

• To manage members and roles: call list_guild_members (or search_guild_members) to locate a user_id and get_guild / list_guild_roles to find a role_id.

If the user supplies a human name (server name, channel name, username#discriminator), resolve that by the appropriate list/get endpoint rather than assuming an ID format.

Common tasks and the operation pattern to accomplish them

Each task below lists the minimal sequence of operations that produce the IDs required for the next call; responses referenced are the typical returns you can rely on.

Send a message to a guild channel:

• Obtain guild_id (if not given) with list_my_guilds or get_guild.
• Get channels with list_guild_channels, pick the channel by name or type, take channel_id.
• Call create_message with channel_id. The response is MessageResponse (contains id, author, content, etc.).

Send a DM to a user:

• Call create_dm with the recipient user ID(s); response is a DM channel object with id.
• Call create_message with that channel_id.

Edit or delete a message:

• Use get_message (or list_messages) to get message_id and verify ownership/permissions.
• Call update_message or delete_message with channel_id + message_id.

React to a message and inspect reactions:

• Add your reaction with add_my_message_reaction (requires emoji_name for unicode or custom emoji format — see Gotchas).
• List voters with list_message_reactions_by_emoji (returns UserResponse[]).
• Remove reactions with delete_my_message_reaction or delete_all_message_reactions.

Create and use a webhook:

• Create in a channel with create_webhook (returns the webhook object; stored tokens are often returned there).
• Post with execute_webhook (use webhook_id and webhook_token). You can include thread_id as a query param to post into a thread in that channel.
• Update or delete webhook messages with update_webhook_message / delete_webhook_message (require webhook_id, webhook_token, and message_id).

Create and manage application (slash) commands:

• Use list_application_commands (global) or list_guild_application_commands (guild-scoped) to see existing commands for application_id.
• Create with create_application_command or create_guild_application_command (choose global vs guild based on scope).
• For per-guild permissions, use get_guild_application_command_permissions / set_guild_application_command_permissions.

Manage guild members and roles:

• Find the member with list_guild_members or search_guild_members.
• Create a role with create_guild_role; add it to a user with add_guild_member_role or update multiple roles via update_guild_member.
• Ban/unban with ban_user_from_guild and unban_user_from_guild (both require guild_id + user_id).

Threads and private archives:

• Create threads with create_thread or create_thread_from_message (requires channel_id, and optionally message_id for message-threading).
• Join/leave threads with join_thread / leave_thread; add/remove thread members with add_thread_member / delete_thread_member.
• Use list_thread_members / get_thread_member to inspect membership. Threads are returned by the same channel endpoints and appear in union channel responses.

Application entitlements and SKU flow:

• Entitlements are application-scoped: call create_entitlement and get_entitlements with application_id. Filtering by user_id, sku_ids, guild_id, and only_active narrows results.

Lobbies and related flows:

• Create or join with create_or_join_lobby (returns LobbyResponse); use create_lobby_message and list_lobby_messages for lobby chat; manage members with add_lobby_member, bulk_update_lobby_members, and delete_lobby_member.

Response patterns and unions you must handle

Many endpoints return union types because the same endpoint can return several concrete resource shapes depending on context (for example, get_channel may return a GuildChannelResponse, PrivateChannelResponse, PrivateGroupChannelResponse, or ThreadResponse). Do not assume a fixed shape: inspect the returned object's discriminating fields (type, presence of guild_id, owner_id, permissions, member sub-object, etc.) to decide the next step.

Some list endpoints return null rather than an empty array. Treat null as “no results.” Several bulk endpoints return arrays of result objects or null entries where items failed or didn’t exist.

Several update/create endpoints return slightly different concrete types depending on inputs (for example, scheduled events and auto-moderation rules can return one of several variant response objects). Rely on discriminant fields in the response rather than a single expected type.

Non‑obvious behaviors and gotchas

• Webhook tokens vs application/bot tokens: webhook operations that accept webhook_id + webhook_token allow posting, editing, and deleting webhook messages without the bot token. Interaction follow-ups use the same webhook-style endpoints anchored to application_id and interaction_token. Webhook-based endpoints also accept an optional thread_id query parameter to post into threads.

• emoji_name format for reactions: unicode emoji should be provided as the literal emoji; custom guild emojis use the name:id format (the path parameter accepts either form). The bridge encodes values, but you must pass the emoji in the correct textual form.

• Interaction responses vs webhooks: create_interaction_response uses interaction_id + interaction_token. To edit or delete the original interaction message, use the webhook-style endpoints with webhook_id = your application_id and webhook_token = the interaction_token.

• Expansion flags reduce extra calls: many endpoints offer query flags such as with_member, with_counts, with_user_count, and with_localizations. Use these to obtain joined or expanded data in a single call instead of making separate list/get calls.

• Global vs guild-scoped commands: creating a global application command (create_application_command) affects all guilds but can take time to propagate; guild-scoped commands (create_guild_application_command) are immediate and suitable for testing. Managing per-guild permissions requires the application_id and guild_id.

• Some create/update endpoints are marked with no response body (unknown) in this specification. Don’t assume a returned resource is always present; if you need the created resource’s ID, follow the create call with the appropriate get/list endpoint to retrieve it.

• Lists and pagination: list endpoints commonly accept limit, before, and after. If a user requests more results than a single list call returns, call the list endpoint again with before/after or other filters; many list endpoints provide deterministic ordering useful for paging.

• Rate limiting and 429 responses: many routes are rate limited per-route and per-bucket. If a request returns a rate-limited response, the response body and headers indicate retry information. (The bridge surfaces the status and body; use the information returned to decide the next call.)

Practical tips for common user asks

• When a user asks to "post in channel X in server Y", resolve guild_id with list_my_guilds or get_guild, then find the channel_id via list_guild_channels before calling create_message.

• When asked to "message user Z", create or fetch a DM channel with create_dm and use the returned channel_id.

• When the request involves moderation (ban, role change, prune): find the user_id by list_guild_members or search_guild_members, confirm the role_id with list_guild_roles, then call ban_user_from_guild, add_guild_member_role, or prune_guild as appropriate.

• For slash command lifecycle: fetch application_id via get_my_application, list existing commands, then create/update via create_application_command/update_application_command or their guild equivalents. Use bulk set endpoints when replacing all commands.

• For interaction follow-ups and edits: use create_interaction_response for the initial callback. To edit or delete the original interaction response, use the webhook-style endpoints with webhook_id = application_id and webhook_token = interaction_token.

Focus on obtaining the specific IDs the next operation requires, and prefer endpoints that return expanded objects (via with_... flags) to reduce additional lookups. When a response is a union or optional, inspect discriminating fields rather than assuming a structure. This will keep workflows straightforward and predictable across the many resource variations the Discord API exposes.