Home / Blog / API Design Interview Starter Template

API Design Interview Starter Template

Published 2026-09-28 · Luna Interview

API design interviews go sideways when candidates jump straight to endpoints without clarifying users, resources, or consistency rules. A starter template keeps you oriented under pressure and gives the interviewer a clear structure to follow.

This API design interview starter template is a talk track plus checklist—not a one-size schema for every product. Steal the order; invent the details for the prompt in front of you.

Minute 0–5: clarify before endpoints

Ask and write answers:

1. Who is the client? (mobile app, internal service, public partners)
2. Core use cases (top 3 user journeys)
3. Consistency needs (strong vs eventual)
4. Scale ballpark (QPS, payload size, read/write ratio)—order of magnitude only
5. Auth model (user tokens, service-to-service, API keys)
6. Sync vs async expectations for slow operations

Talk track:

“I’ll confirm actors and the top three flows, then propose resources and methods before diving into edge cases.”

If the interviewer withholds scale numbers, state assumptions out loud and proceed. Invented precision without labeling it is worse than a labeled guess.

Resource model first

Name nouns, not actions:

• Prefer /orders and /orders/{id} over /createOrder
• Identify relationships: user → orders → line items
• Decide identifiers: opaque IDs vs readable slugs
• Note what is sub-resource vs top-level

Sketch on the board:

User
 Order
  LineItem
 PaymentIntent (async)

Call out cardinality (“an order has many line items”) so later pagination and nesting choices make sense.

Method and URL template

For each core resource, fill:

Call out when POST on a custom action is justified (/orders/{id}/cancel) versus overusing verbs. Prefer nouns until a true state transition needs a dedicated action.

Request / response shape checklist

• Request validation errors → 400 with field-level messages
• Auth failures → 401 / 403 clearly distinguished
• Not found → 404
• Conflict (duplicate create) → 409
• Rate limit → 429 with retry guidance
• Success create → 201 + Location when natural
• Async accept → 202 + status URL

Example error envelope (keep simple):

{
  "error": {
    "code": "validation_failed",
    "message": "email is invalid",
    "fields": {"email": "invalid_format"}
  }
}

Do not invent twelve error formats. One boring envelope is a feature.

Pagination, filtering, sorting

Default talk track:

“List endpoints use cursor pagination for stable large lists; offset only if the dataset is small and clients need pages. Filters are query params allow-listed; sort is explicit and indexed.”

Mention: max page size, default sort, and what happens with unknown filters (ignore vs 400—pick one and justify).

Idempotency and unsafe retries

For payment-like creates:

• Client sends Idempotency-Key
• Server stores response for that key
• Retries return the same result

Say it early if money or duplicate side effects exist. Interviewers listen for whether you volunteer this without being prompted.

Versioning and evolution

Options to mention (pick one primary):

• URL version (/v1/...) for public breaking changes
• Header version when you want cleaner paths
• Additive, backward-compatible fields as the default habit

Talk track:

“I’d start additive and only cut a /v2 when a breaking change is unavoidable; deprecation window communicated in docs.”

Security and tenancy (do not skip)

• Authn vs authz on every resource
• Tenant isolation if multi-tenant
• PII minimization in logs
• Rate limits per client
• Least-privilege scopes for tokens

Even a junior-friendly design round expects you to mention unauthorized access to another user’s resource.

Webhooks and async (when relevant)

If the prompt includes long work:

• Accept with 202
• Provide a status resource
• Optionally push webhooks with signatures and retries

Keep it proportional—do not build an event bus for a CRUD todo list.

Soft practice note

Rehearse this template out loud until the clarify → resources → methods → errors → evolution flow is automatic. If you want a Chrome side panel for calm, structured practice of design talk tracks, Luna Interview can support that rehearsal loop. Use it to build fluency—not to fake expertise or violate interview rules.

End-of-interview wrap script

“Resources are X/Y; primary flows covered by these endpoints; errors use this envelope; lists are cursor-paginated; creates that matter are idempotent; we’ll evolve additively with a version bump only for breaks. Happy to deep-dive rate limiting or the async status resource next.”

One-page starter you can redraw every time

1. Actors + top 3 flows
2. Resource diagram
3. CRUD table for core nouns
4. Error + status code policy
5. Pagination default
6. Idempotency where side effects hurt
7. Authz note
8. Evolution plan

Bring structure; invent endpoints only after the structure is shared.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.