Axios Interceptors and Custom Adapters: Testing an Integration Without Production Credentials

Axios Interceptors and Custom Adapters at the Integration Boundary

Axios exposes two extension points that meet at the same boundary: request and response interceptors, registered through axios.interceptors.request.use() and axios.interceptors.response.use(), and the transport adapter selected through the adapter config option in axios 1.x. Interceptors participate in the request pipeline, while the adapter is the layer responsible for producing a response.

A team that wants to exercise an integration flow without production credentials must decide which of these two layers to substitute. Replacing the adapter keeps interceptor logic such as token attachment, header normalization and error mapping inside the path under test. Ejecting or replacing interceptors instead changes the behavior being observed.

The unresolved part is the interaction between the two: whether a custom adapter receives the config as mutated by request interceptors, and whether response interceptors are applied to the adapter's returned response before caller .then() handlers run. Behavior should be confirmed against the installed axios version.

Which layer should be substituted when credentials are unavailable, and should the test assert on the config handed to the adapter or on the value resolved by the caller?