Explain Discord's Developer API Through Real Example Requests

In a technical round for a product manager role, you are asked to name three endpoints in Discord's API. For each one, explain what it does, how a client would call it, and what comes back. ```hint Follow one everyday action Start from something a user or a bot does all the time in a server, work out which resource that action touches and which HTTP method fits it, and then look at neighboring endpoints on the same resource. ``` ### Clarifying Questions - Should the endpoints come from Discord's public developer API, which bots and integrations use, or from the calls I would expect Discord's own desktop and mobile apps to make? - Do you want exact paths and HTTP methods, or is it enough to describe the resource, the action and the main parameters? - Should I also explain how real-time updates such as new messages reach clients, since that does not happen through ordinary request and response calls? ### What a Strong Answer Covers - Three distinct, plausible endpoints, each with an HTTP method, a resource path and its key parameters - What each call returns, and its main failure cases such as missing permissions, an unknown channel or a rate limit - The concerns that cut across Discord's API: bot versus user authentication, channel permissions, rate limits and paging through message history - The difference between request and response calls and the persistent connection that pushes events to clients - Why a product manager would care: what these endpoints let developers build and which product decisions they encode ### Follow-up Questions - A bot's send request times out and the bot retries. How would you stop the message from appearing twice? - How should a client load the history of a channel that holds millions of messages? - If you owned Discord's developer platform, which API health metric would you watch first, and why?