# Handle API base URL, auth token, and errors via HTTP interceptors

- Status: accepted
- Date: 2026-04-26

## Context and Problem Statement

Every API call requires three cross-cutting concerns: prepending the API base URL, attaching the JWT bearer token, and unwrapping error responses into a consistent shape. How should these be applied across all HTTP calls without duplicating logic in each service?

## Considered Options

- Three chained HTTP interceptors
- Per-service base URL and token handling
- Single utility wrapper function

## Decision Outcome

Chosen option: "Three chained HTTP interceptors", because they centralise cross-cutting concerns transparently and require no changes to individual services.

### Positive Consequences

- Services use relative paths (e.g. `/skydive/jumps`) — environment-agnostic.
- Auth header injection is transparent to all services.
- Uniform error payload shape across the entire application.

### Negative Consequences

- Services must always use relative paths starting with `/`. Passing an absolute URL would cause the base URL to be prepended twice.

## Pros and Cons of the Options

### Three chained HTTP interceptors

- Good, because zero duplication — logic defined once, applied everywhere.
- Good, because services remain unaware of environment or auth details.
- Bad, because interceptors apply globally — opting out requires explicit handling.

### Per-service base URL and token handling

- Good, because each service controls its own behaviour explicitly.
- Bad, because duplicates the same logic across every service.

### Single utility wrapper function

- Good, because more explicit than interceptors.
- Bad, because all service calls must go through the wrapper — easy to bypass accidentally.