30 API Integration Interview Questions for 2026

By Lazar Milicevic · Published September 27, 2026 · 13 min read

You have an interview this week, and "API integrations" is on the job description between "Kubernetes" and "stakeholder communication." You have integrated dozens of APIs, but you have never had to explain why you chose cursor pagination over offset, out loud, to someone taking notes. This guide covers the 30 questions that actually come up — from junior HTTP fundamentals to senior architecture scenarios — with the answers a hiring engineer wants to hear.

Core HTTP and REST Fundamentals

Direct answer: REST is an architectural style (stateless client-server communication over standard HTTP methods), SOAP is a protocol using XML envelopes, and GraphQL is a query language where the client requests exactly the fields it needs. Idempotent methods (GET, PUT, DELETE) can be retried safely; POST and PATCH cannot. That's the core of almost every opening question in this category.

1. What's the difference between REST and SOAP?

REST is an architectural style built on HTTP. SOAP is a formal protocol with a strict XML message envelope, WSDL service definitions, and built-in standards for security (WS-Security) and transactions. Roy Fielding, who coined REST in his 2000 doctoral dissertation, defined it as a set of architectural constraints — statelessness, a uniform interface, layered systems — not "JSON over HTTP," which is how it's commonly (mis)used.

SOAP survives mainly in enterprise and financial systems (payment processors, legacy ERPs) where its strict contracts and WS-Security matter. Everything else has moved to REST or GraphQL.

2. Map HTTP methods to CRUD operations. What's the difference between PUT and PATCH?

POST creates, GET reads, PUT/PATCH update, DELETE removes. PUT replaces a resource completely — send the full object or unspecified fields get wiped. PATCH applies a partial update — send only the fields you want changed. Interviewers probe this because confusing them causes real production bugs.

3. What does idempotent mean, and which HTTP methods are idempotent?

An idempotent request produces the same server-side effect whether you call it once or ten times. GET, PUT, and DELETE are idempotent. POST is not — calling it twice creates two resources. This distinction is the foundation of every retry strategy, and it comes up again in Questions 18 and 25.

4. What does "stateless" mean in REST?

Every request contains everything the server needs to process it. No session memory on the server between calls. The implication: authentication credentials ride on every request, and scaling is trivial because any server instance can handle any request.

5. Explain the main HTTP status code classes — and name the ones you use daily.

• 1xx – informational (rarely seen in integrations)
• 2xx – success: 200 OK, 201 Created, 204 No Content
• 3xx – redirects: 301 permanent, 304 Not Modified (critical for caching — see Question 23)
• 4xx – client errors: 400 malformed, 401 unauthenticated, 403 unauthorized, 404 missing, 409 conflict, 422 valid JSON but failed validation, 429 rate limited
• 5xx – server errors: 500, 502 Bad Gateway, 503 Service Unavailable

Know the difference between 401 and 403 cold — it gets asked constantly. The canonical reference is RFC 9110 and MDN's status code documentation.

6. When would you choose GraphQL over REST?

When clients need flexible, nested data (a mobile app pulling a user, their orders, and each order's items in one round trip), and when over-fetching hurts performance. The trade-off: caching is harder, query complexity can become a server-side cost problem, and N+1 resolver bugs are easy to introduce. Experienced candidates name both sides unprompted.

API Authentication and Security

Direct answer: API keys identify a project, OAuth 2.0 authorizes delegated access on behalf of a user, and JWTs are a compact token format often used to carry OAuth grants. Store secrets in environment variables or a secrets manager — never in code or client-side JavaScript — and always verify webhook signatures with HMAC. Per OWASP, broken object-level authorization and broken authentication are the top two API vulnerabilities, so expect follow-up questions here.

7. What's the difference between API keys, OAuth 2.0, and JWT?

• API key – a static secret identifying a project or application. Simple, but it grants whatever access it's given, with no scoping or expiry by default.
• OAuth 2.0 – a delegation framework (RFC 6749) where a user grants an app limited access without sharing credentials. Uses short-lived access tokens plus long-lived refresh tokens.
• JWT (JSON Web Token) – a signed, encoded token format, not an auth protocol by itself. An OAuth access token is often a JWT containing claims (user, scopes, expiry) that the server verifies via signature without a database lookup.

8. Explain the OAuth 2.0 flows you'd actually use.

Two matter in practice. Authorization code flow with PKCE — for anything with a user present: redirect to the provider, user consents, app exchanges the code for tokens. PKCE prevents authorization-code interception in mobile and SPA apps. Client credentials flow — for server-to-server integration with no user: the client authenticates directly with its client ID and secret and receives an access token.

Mention that implicit flow is deprecated for new apps. That single detail signals you've read current guidance rather than a 2018 tutorial.

9. Where do you store API keys?

Server-side only — environment variables at minimum, a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) in anything serious. Keys in client-side JavaScript are visible to anyone. Rotate keys on a schedule and on any suspected exposure, and scope each key to the minimum permissions it needs. A leaked key with read-only access to one endpoint is an incident; a leaked admin key is a breach.

10. How do you handle token expiration and refresh?

Cache the token, check expiry before each call (or handle 401s as a fallback), and refresh proactively using the refresh token rather than waiting for failure. Two traps: never refresh on every request (many providers rate-limit token endpoints aggressively), and never let two concurrent threads trigger simultaneous refreshes — lock the refresh.

11. How do you secure incoming webhooks?

Verify the signature on every event. Legitimate providers sign the payload with a shared secret; if the HMAC doesn't match, drop the request. Also enforce TLS, reject stale events by checking timestamps, and never trust metadata like event IDs or amounts without cross-checking via the provider's API for anything involving money.

12. What's in the OWASP API Security Top 10, and which ones have you defended against?

The OWASP API Security Top 10 (2023 edition) is led by Broken Object Level Authorization (IDOR — changing /users/1234 to /users/1235 and getting data) and Broken Authentication. Beyond those: excessive data exposure (returning full objects and filtering client-side), unrestricted resource consumption, and broken function-level authorization. Have one concrete story ready for each of the top two — interviewers ask for examples immediately.

Error Handling, Retries, and Resilience

Direct answer: Retry only idempotent operations and transient errors (5xx, 429, network timeouts) with exponential backoff plus jitter — never retry 4xx client errors, which will fail identically every time. Layer timeouts, retries, and a circuit breaker so a failing dependency degrades gracefully instead of cascading. In chained workflows, use idempotency keys and compensation steps to avoid half-completed states.

13. How should a well-designed API error response look?

Machine-readable and consistent. A stable error code, human-readable message, the request ID for support correlation, and structured field-level details for validation failures:

{
  "error": {
    "code": "invalid_invoice_amount",
    "message": "Invoice total must be a positive number.",
    "request_id": "req_9f2ac41d",
    "fields": { "total": "must be greater than 0" }
  }
}

14. What's the correct retry strategy for a failed API call?

Retry only transient failures — 5xx, 429, connection errors. Never retry 400-level errors. Use exponential backoff with jitter, and cap total attempts:

import random, time, requests

def call_with_retry(url, payload, max_attempts=5):
    for attempt in range(max_attempts):
        try:
            resp = requests.post(url, json=payload, timeout=10)
            if resp.status_code < 400:
                return resp
            if resp.status_code < 500 and resp.status_code != 429:
                resp.raise_for_status()  # client error: don't retry
        except requests.RequestException:
            if attempt == max_attempts - 1:
                raise
        time.sleep(min(2 ** attempt, 30) + random.random())  # backoff + jitter
    raise RuntimeError("max retries exceeded")

The jitter matters: without it, all your retrying clients hammer the recovering server in synchronized waves.

15. What is a circuit breaker?

A wrapper around a failing dependency that "opens" after a threshold of failures and fails fast for a cooldown period instead of burning timeouts on every call. Half-open state lets a single probe through to test recovery. It protects your system when a downstream API is down and prevents retry storms from making the outage worse.

16. How do you set timeouts?

Always set them, and split them: a connect timeout (seconds — if you can't establish a TCP connection, something is wrong) and a read timeout (depends on the endpoint; a report-generation call may legitimately need minutes). An integration with no timeout will eventually hang a worker forever. Say this and you've separated yourself from most candidates.

17. How do you handle partial failure in a multi-step workflow?

Design each step to be idempotent, persist workflow state between steps, and on failure either resume from the failed step or run a compensation (credit back what you charged, cancel what you created). This is the saga pattern — the senior-candidate term that earns a nod from interviewers.

18. How do idempotency keys prevent duplicate charges?

The client generates a unique key per logical operation and sends it with the request. The server stores the key and the result — if the same key arrives again (network retry, double-click, webhook redelivery), it returns the original result instead of re-executing. Stripe's API popularized this, and payment integrations are where interviewers expect you to bring it up unprompted.

Rate Limiting, Pagination, and Data Volume

Direct answer: Respect the provider's rate limit headers (X-RateLimit-Remaining, Retry-After), back off when you hit 429, and prefer cursor pagination over offset for large datasets — offset gets slower and can skip or duplicate rows when data changes during the walk. For syncs, use incremental updates with If-Modified-Since or ETag conditional requests instead of re-fetching everything.

19. How does rate limiting work, and how do you detect it?

Providers throttle per key/token/IP over a time window. They signal limits via response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) and via 429 plus Retry-After when you exceed them. Correct handling: honor Retry-After, not your own guess.

20. What strategies keep you under the limit?

Cache responses with appropriate TTLs, batch operations where the API offers bulk endpoints, use webhooks instead of polling where available, distribute work across a queue so requests arrive at a controlled rate (token-bucket style), and request only the fields you need.

21. Offset vs. cursor pagination — which and why?

Offset (?page=3&limit=50) is simple but degrades on deep pages (the database scans and discards every preceding row) and is unstable under concurrent inserts — rows shift, causing duplicates or skips. Cursor pagination (?after=eyJpZCI6MTIzfQ) uses an indexed column (usually a timestamp or ID) as the bookmark: consistent under concurrent writes and roughly constant cost at any depth. Every senior answer includes the instability point.

22. How do you sync a large dataset from a third-party API?

Initial load with cursor pagination, persisted to your store. Incremental syncs afterward using updated_since filters if offered, or conditional requests (Question 23). Queue the work, checkpoint progress so a crash resumes rather than restarts, and reconcile counts periodically (Question 29).

23. What is an ETag / conditional request?

The server responds with an ETag — a version fingerprint of the resource. On the next poll, the client sends If-None-Match with that ETag; if nothing changed, the server returns 304 Not Modified with an empty body. For sync jobs this cuts bandwidth and processing dramatically on the common case where nothing changed.

Webhooks and Event-Driven Integration

Direct answer: Webhooks push events to you instead of you polling — but your handler must acknowledge fast (return 2xx immediately), process asynchronously, verify the HMAC signature, and deduplicate by event ID, because providers redeliver aggressively. Never do heavy work inside the HTTP request/response cycle.

24. Webhooks vs. polling — trade-offs?

Polling is simple and resilient (you control the schedule) but wasteful and high-latency. Webhooks are near-real-time and efficient but introduce a public endpoint, delivery-order and at-least-once semantics, and debugging difficulty (you can't re-run a request you never saw). Production systems often use webhooks plus a scheduled reconciliation poll as a safety net.

25. How do you build a reliable webhook receiver?

• Return 2xx immediately; process the event in a queue (a slow response triggers redelivery storms).
• Verify the signature before anything else.
• Deduplicate by event ID — providers deliver at least once.
• Make processing idempotent (Question 18), so a redelivery is harmless.

26. How do you verify a webhook signature?

import hmac, hashlib

def verify_signature(raw_body: bytes, signature: str, secret: str) -> bool:
    expected = hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(f"sha256={expected}", signature)

Two details interviewers want: hash the raw body (any JSON re-serialization breaks the signature), and use a constant-time comparison to avoid timing attacks.

27. What happens when your endpoint is down?

Providers retry with backoff over hours to days, but you can't rely on that alone. Serious integrations add: a dead-letter queue for events that fail processing after N attempts, periodic polling-based catch-up as a backstop, and monitoring on delivery failure webhooks (many providers send "your endpoint is failing" alerts — wire them to PagerDuty, not an inbox).

Senior-Level Scenario Questions

Direct answer: For a flaky third-party API, the senior answer combines contract testing, sandbox validation, circuit breaking, and a rollout plan that includes deprecation timelines and client communication — not just code. For data drift between systems, you build scheduled reconciliation, not one-off fixes.

28. "Design an integration with a notoriously unreliable third-party API."

Structure the answer in layers: (1) Contract first — mock their API from their docs with contract tests in CI so you catch breaking changes on your side. (2) Resilience — retries with jitter, circuit breaker, timeouts, a queue decoupling your system from theirs. (3) Observability — log request IDs both sides, alert on error-rate and latency budgets. (4) Degradation plan — what does your product do when the API is down: queue, stale cache, or explicit user-facing failure? Interviewers are grading whether you think beyond the happy path.

29. "Two systems disagree about the same data. Walk me through reconciliation."

Don't answer "fix the bad rows." Describe a process: a scheduled job comparing both sides on keys that matter, a quarantine/report for mismatches, a defined source of truth per field, and an audit trail of every automated correction. The senior insight: disagreeing data is a recurring condition you engineer for, not a one-time bug.

30. "How do you version an API and deprecate an endpoint without breaking clients?"

Additive changes (new optional fields) need no version. Breaking changes get a new major version path (/v2/), sunset headers on the old version announcing the deprecation date, documented migration guides, and error responses on the old version after shutdown that point clients to the replacement. Mention that you keep old versions running with a communicated end-of-life — the cost of betraying client trust exceeds the cost of maintaining one more route.

How BizFlowAI approaches this

Every automation we ship for clients — invoice syncing between accounting platforms, lead routing into CRMs, payment reconciliation — is built from the patterns above: cursor-paginated syncs with checkpoints, HMAC-verified webhooks processed from queues, idempotency keys on anything that moves money. These aren't interview abstractions; they're the difference between an integration that silently duplicates a client's invoices at 3 a.m. and one that runs for a year without a page.

We maintain contract tests for every third-party API we depend on, because we've been burned by "minor" provider changes more often than by outages. If you're building integrations under real constraints and want to see how this looks in production — or if you're interviewing and want war stories that go deeper than this guide — the engineering notes on this blog are where we document what actually breaks.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.