Flutter · One codebase, native feel

How do you structure networking and API error handling?

MediumnetworkinghttpdioerrorsUpdated Oct 2026
Quiz this track

Short answer

Wrap HTTP calls in a client with timeouts, typed decoding and explicit error mapping. Add retries only for safe or idempotent requests, and keep tokens in secure storage rather than logs or source.

I keep transport concerns in one client and map responses into domain models. The UI should not know about status codes. Timeouts, cancellation, retry policy and auth refresh belong at that boundary, with logging that redacts tokens and personal data.

dart
Future<List<Repo>> fetchRepos(http.Client client) async {
  final uri = Uri.parse('https://api.example.com/repos');
  final response = await client
      .get(uri, headers: {'Accept': 'application/json'})
      .timeout(const Duration(seconds: 10));

  if (response.statusCode != 200) {
    throw ApiException('HTTP ' + response.statusCode.toString());
  }

  final decoded = jsonDecode(response.body) as List<dynamic>;
  return decoded
      .map((item) => Repo.fromJson(item as Map<String, dynamic>))
      .toList();
}
  • Set connect and receive timeouts; the default may be too long for mobile networks
  • Retry with exponential backoff and jitter only for transient, idempotent failures
  • Do not retry a payment or create call unless the server supports idempotency keys
  • Cancel requests when the screen is disposed or superseded
  • Never log authorization headers, tokens or full response bodies containing personal data

Auth refresh and errors

Handle token refresh in one interceptor or client wrapper, serialising concurrent refreshes so many requests do not trigger many refreshes. Map network, timeout, unauthorised, rate limited and server errors into distinct states. The UI needs to tell the user whether retrying is useful.

Certificate pinning raises security but adds operational risk. Pins must have a rotation and backup plan, or an expired certificate becomes a hard outage.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1How do you prevent a thundering herd of token refreshes?
  2. 2Which HTTP methods are safe to retry automatically?
  3. 3How do you distinguish offline from a server error?
  4. 4What are the risks of certificate pinning?

Say it in the interview

I keep HTTP behind a client that owns timeouts, auth refresh, error mapping and redacted logging. Callers receive typed results or domain exceptions, not raw status codes. Retries use backoff and only apply to transient idempotent calls. I also cancel stale requests, show whether a failure is retryable, and only add certificate pinning with a rotation plan.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Flutter mock interview and get scored feedback on depth, clarity and confidence.