Robinhood API Design: Endpoints for Onboarding, Funding, Market Data and Orders

Robinhood's mobile and web apps run on backend APIs. What are some of the endpoints you would expect Robinhood to have? ```hint Before the first trade List what a new customer has to do before they can buy anything, and separate the calls that move money or create orders from the calls that only display data. ``` ### Clarifying Questions - Do you want the endpoints the customer app calls, or also internal ones, such as those that send orders to trading venues? - Which products are in scope: stocks and ETFs only, or also options, crypto and retirement accounts? - How much detail do you want: a list of resources, or the request, response and error cases for one important endpoint? ### What a Strong Answer Covers - The core domains: sign-in and identity verification, bank linking and transfers, market data, orders, and positions and account history - Correct API mechanics, with authentication suited to a financial app (multi-factor sign-in, short-lived tokens, step-up checks for sensitive actions) - Depth on placing an order: order types, validation such as buying power, idempotency, and an asynchronous status lifecycle - Separating streamed real-time data (quotes, order updates) from request and response calls, and what to protect when load spikes - How regulation and risk shape the API: identity checks, trading restrictions and record keeping ### Follow-up Questions - A customer taps Buy, the request times out and they tap again. How do you prevent a duplicate order? - On a day of extreme market volatility, traffic surges. Which endpoints do you protect first, and how? - A customer cancels an order at the same moment it fills. What should the cancel endpoint return?