API Design in System Design Interviews

So you’ve done the first part of the interview well:

• You asked your clarifying questions and pinned down the requirements.
• You agreed on the scope out loud, like “let’s build posting and a feed, skip messaging for now”.
• Now there’s this little gap before you start drawing boxes, and a lot of people rush right past it.

Here’s the thing. Right after requirements, the smartest move is to define the API. It sounds fancy, but all it means is writing down the exact requests a client can make. And once you’ve done that, the system stops being fuzzy. You know exactly what it does, because you’ve listed every action it supports.

🎯 Why Design the API

Let me tell you the pain first:

• You skip the API and jump straight to boxes and arrows.
• Halfway through, the interviewer asks “okay, so how does a user actually post something?” and you freeze.
• You realize you’ve been drawing a system without knowing what it’s supposed to do.

Defining the API fixes that before it happens. So why is it such a strong move?

• It turns fuzzy features into concrete operations. “Users can post” becomes a real request with a method, a path, an input, and an output.
• It sets the API contract. The contract is just the agreement on what each request takes in and what it gives back, so the client and the server both know what to expect.
• It keeps you and the interviewer pointed at the same target. Everyone can see, in plain text, what the system promises to do.

The thing is, this step is quick. You spend a few minutes here, and the whole rest of the design gets easier, because now you’re building servers and databases to support a clear list of operations.

🔌 What to Define

Okay so what does “define the API” actually mean? You go through each core feature you scoped, and for every one of them, you write down four things:

• The method. This is the kind of action. An HTTP method is the verb of the request. GET reads something, POST creates something, PUT updates, DELETE removes. So the method tells you at a glance whether this request reads data or changes it.
• The path. This is the address of the thing you’re acting on, like /posts or /feed. It names the resource, which is just whatever the request is about, a post, a user, a feed.
• The inputs. This is what the client has to send. For creating a post, that’s the text and maybe the user’s ID. Be specific about what goes in.
• The outputs. This is what the server sends back. For creating a post, maybe the new post’s ID. For reading a feed, a list of posts.

Here’s how one request flows once you’ve defined it. The client sends a request to a specific endpoint, the server does its work, and a response comes back.

Do this for each core feature and you’ve got your whole API. Each endpoint maps to exactly one thing a user can do. That’s the goal.

⌨️ A Few Endpoints

Let’s make this real. Say we scoped a simple social app where people can post and scroll a feed. Here are a couple of endpoints, written the way you’d jot them on the whiteboard.

First, creating a post. A user sends some text, and we hand back an ID for the new post.

POST /posts
  Input:  { userId, text }
  Output: { postId, createdAt }

Let’s read what that says:

• POST is the method, so we know this request creates something new.
• /posts is the path, the collection of posts we’re adding to.
• The input is the user’s ID and the text they typed.
• The output is the new post’s ID and when it was made, so the client can show it right away.

Next, reading the feed. The user asks for their feed, and we send back a list of posts.

GET /feed?userId=42&page=1
  Input:  userId, page number
  Output: { posts: [ ... ], nextPage }

Reading this one:

• GET is the method, so this just reads data, it doesn’t change anything.
• /feed is the path, and the bits after the ? are query parameters, which are little extra inputs tacked onto the path.
• We ask for a page because a feed can be huge, so we grab it a chunk at a time.
• The output is the list of posts plus a nextPage marker, so the client knows how to ask for more.

And one more, fetching a single post by its ID.

GET /posts/{postId}
  Input:  postId (in the path)
  Output: { postId, userId, text, createdAt }

See how this reads almost like plain English? Anyone glancing at these three lines knows what the system does. That’s the whole point. You’ve turned “people can post and scroll a feed” into concrete operations the rest of your design has to support.

📋 Feature to Endpoint

A neat way to show your thinking is to line up each feature next to the endpoint that handles it. It proves every feature you scoped has a home, and nothing extra snuck in.

Lay it out like this and the interviewer can see your whole system at a glance. It also catches gaps fast. If a feature has no endpoint, you missed something. If an endpoint has no feature, you’re building stuff nobody asked for.

🧩 Keep It Focused

Now here’s a trap that’s easy to fall into. You start listing endpoints, and you overdo it:

• You add PUT /posts/{postId} for editing, then DELETE for removing, then endpoints for drafts, bookmarks, reports, and on and on.
• None of that was in the scope you agreed on. You scoped posting and a feed.
• So now you’re burning interview minutes designing things the interviewer never asked for.

The fix is simple. Only design the API for the core features you scoped:

• Look back at the scope you pinned down in the requirements step. That’s your list.
• One endpoint per core feature is plenty to show you understand the system.
• If the interviewer wants more later, they’ll ask. You can always add an endpoint on the spot.

Think of the API as a sketch of the system, not the full manual. A tight, focused API says you know what matters. A giant pile of endpoints just says you can’t tell the core from the extras.

🔑 Small Things That Impress

Once your core endpoints are down, a few light touches make you sound like you’ve actually built APIs before. You don’t need to go deep, just mention them.

• Pagination for lists. Any endpoint that returns a list, like the feed, shouldn’t dump a million items at once. So you return one page at a time, using a page or a cursor. Mentioning this shows you’re thinking about real-world scale.
• Auth where it’s needed. Some actions need to know who’s calling, like posting or following. Auth, short for authentication, is just the system checking who you are, usually with a token sent along in the request. Point out which endpoints need it.
• Sensible status codes. A status code is the short number the response sends back to say how it went. Use 201 when you create something, 200 for a successful read, 404 when the thing isn’t found, 401 when the caller isn’t logged in. Picking the right ones shows polish.

One line on each of these during the interview is enough. It signals maturity without eating your time.

⚠️ Common Mistakes and Misconceptions

A few habits trip people up at this step. Let’s clear them out.

• “Skip the API and jump straight to boxes.” This is the big one. If you draw servers and databases before defining what the system does, your design has no anchor. Define the API first, then the boxes have a clear job.
• “Design every possible endpoint.” More endpoints don’t make you look thorough, they make you look unfocused. Stick to the core features you scoped, and stop there.
• “Ignore the inputs and outputs.” Writing just POST /posts and moving on isn’t enough. The contract lives in what goes in and what comes back. Spell those out, even briefly, or the endpoint doesn’t really mean anything.
• “Treat the API as the final answer.” It’s a sketch to guide the design, not a finished spec. It’s fine to refine it as the interview goes on.

🛠️ Practice Challenge

Time to try it yourself. Take this prompt: “Design a simple to-do app, where a user can create tasks, see their list of tasks, mark a task done, and delete a task.”

Walk through the API the same way we just did:

• List the core features. Create a task, list tasks, mark done, delete. That’s your scope.
• Write an endpoint for each. Pick the method, the path, the inputs, and the outputs. For example, POST /tasks with input { userId, text } and output { taskId }.
• Add the small touches. Where would you paginate? Which endpoints need auth? What status code would you return when a task is created?
• Check your list. Does every feature have exactly one endpoint? Did any extra endpoint sneak in that wasn’t in the scope?

Do this on paper, out loud, like Alex is sitting across from you grading it. The more you rehearse turning features into clean endpoints, the faster this step goes in a real interview.

🧩 What You’ve Learned

You can now define the API for a system in an interview, cleanly and quickly. Here’s what you’ve picked up.

• ✅ Define the API right after requirements, before you draw any boxes.
• ✅ For each core feature, write the method, the path, the inputs, and the outputs.
• ✅ The inputs and outputs are the API contract, the promise of what goes in and what comes back.
• ✅ Map one endpoint to each scoped feature, and keep it focused, no extras.
• ✅ Mention pagination for lists, auth where it’s needed, and sensible status codes.
• ✅ Treat the API as a sketch that guides the design, not a final spec.

🚀 What’s Next?

With the API defined, you know exactly what the system does. Next, you build the pieces that make those endpoints work.

• Database Selection Strategy helps you pick the right store for the data your endpoints read and write.
• REST APIs Explained goes deeper into how real APIs are designed, with methods, paths, and status codes in full.

Define the API on a few small prompts, and pretty soon turning fuzzy features into clean endpoints will feel automatic.