Apisauce: a thin Axios wrapper with one response shape, now community supported

The problem Apisauce solves: two branches for every request

Plain Axios gives you two flows. A 2xx status lands in `.then`, and everything else, including a 404 that is a perfectly normal answer from an API, lands in `.catch`. Calling code ends up with duplicated parsing and error handling, and the shape of what you get back differs depending on whether the server answered at all.

Apisauce changes that contract. The README states that the promise is always resolved with a response object, even if there was a problem with the request, and that this is one of the goals of the library. A response always carries `ok` (true when the status code is in the 200s) and `problem`, a string with one of six values. When the request reached the server, you also get `data`, `status`, `headers`, `config` and `duration`.

The audience is narrow and identifiable: teams writing React Native apps, which is one of the topics on the repository and the platform where the README claims connection-issue detection. It is also a reasonable fit for browser and Node code that talks to several endpoints and wants one error vocabulary across them.

How the wrapper is built: create, monitors, transforms

You do not subclass Axios. You call `create` with a configuration object and get back an object with methods for `get`, `head`, `delete`, `link`, `unlink`, `post`, `put`, `patch` and `any`. The only required property is `baseURL`, and the README notes it can contain a sub-path and a port. The package depends on `axios` (the declared range is `^1.11.0`) and is built with TypeScript, so the published type definitions ship alongside the bundle.

Two extension points sit in the request path. Monitors are functions attached with `addMonitor` that run just before the promise resolves; the README says you cannot change anything, only look, and that each callback is wrapped in a try/catch so an exception inside a monitor does not affect the request. Transforms are the opposite: they can change every request or response globally, and the README warns that exceptions in transforms are not swallowed and will bring down the stack.

That asymmetry is the main design decision worth knowing about. Logging and metrics belong in monitors because they are safe. Header rewriting and response repair belong in transforms, and you accept that a bug there breaks every call on that instance. The README also documents mutating an instance after creation with `setBaseURL`, `getBaseURL`, `setHeader` and `setHeaders`, which means a token refresh can be applied to one shared api object rather than threaded through call sites.

Installing Apisauce and making a first call

The README gives two install commands. Pick the one that matches your package manager; both pull in Axios as a dependency.

npm i apisauce --save

Or, with Yarn:

yarn add apisauce

Then create an api object and call it. The README's quick start uses the GitHub API and an Accept header for the v3 media type.

import { create } from 'apisauce'

const api = create({
  baseURL: 'https://api.github.com',
  headers: { Accept: 'application/vnd.github.v3+json' },
})

api
  .get('/repos/skellock/apisauce/commits')
  .then(response => response.data[0].commit.message)
  .then(console.log)

What you should see is a commit message printed to the console. Note that the `.then` chain does not check `ok` first. That is the point of the library, and it is also the trap: a failed request still resolves, so `response.data` can be undefined and `response.data[0]` will throw a TypeError that looks nothing like a network error. Guard on `ok` before touching `data`.

Per-request headers go in the third argument for `get`, `head`, `delete`, `link` and `unlink`, and in the third argument for `post`, `put` and `patch` after the body. The README's example of the latter is:

api.post('/users', { name: 'steve' }, { headers: { 'x-gigawatts': '1.21' } })

If you already have a configured Axios instance, the README shows passing it in as `axiosInstance` instead of `baseURL`, which is the cleanest way to keep interceptors you have already written.

Where Apisauce gets in the way

The always-resolve contract is a real cost, not a convenience. Every call site has to remember that a rejected promise is not how failures arrive, and TypeScript will not stop you from reading `response.data` on a response where `ok` is false. The library gives you `problem` as a string code rather than a typed error object, so mapping a problem to user-facing copy is your job.

There is a second, sharper limitation. The README's own banner says Apisauce is no longer actively maintained, that Infinite Red will release security patches submitted by the community, and that it is not recommended for new projects. The last push to the repository was on 2026-06-12, and the most recent release listed is v3.2.2 from 2025-11-25. That is not an abandoned repository, but it is a maintenance posture you should read literally: fixes arrive when someone outside the project sends them.

Finally, the abstraction is thin enough that it is the wrong tool if you need interceptors, retries, cancellation or streaming. Those are Axios features, and Apisauce is described as a low-fat wrapper rather than a replacement. If your HTTP layer needs more than a uniform response object, you are paying an extra dependency for very little.

Apisauce vs calling Axios directly

The honest comparison is with Axios itself, because the README recommends exactly that. Axios gives you interceptors that can modify requests and responses, a rejection-based error model that composes with `try`/`catch`, and a much larger surface for cancellation and configuration. Apisauce gives you one resolved response shape, the six-value `problem` field, monitors, and transforms.

So the difference is not capability, it is where the branching lives. With Axios, error handling is spread across `.catch` blocks or a global interceptor. With Apisauce, it is a single `if (!response.ok)` at each call site, plus whatever monitor you attach to log the `problem` value. If your team keeps forgetting to handle failures, the wrapper's shape is a genuine improvement. If your team already has a well-tested Axios instance with interceptors, wrapping it mostly adds a second vocabulary for the same events.

The README's suggestion, building your own wrapper around Axios, is a smaller job than it sounds: the interesting part of Apisauce is the response contract, and that is a few dozen lines. What you would have to reproduce yourself is the monitor and transform plumbing and the React Native connection-issue detection the feature list mentions.

Licence and upgrade cost

Apisauce is MIT licensed, and the licence file sits at the repository root. For most consumers that means permissive use with attribution requirements you should read in the LICENSE file rather than take from an article. The published package includes the built bundle, a UMD build and `apisauce.d.ts`, so TypeScript users get types without a separate install.

Upgrade cost is low in the normal case, because the public surface is a small set of methods and the dependency is a single range on Axios. The risk is on the Axios side: a future Axios major could change behaviour the wrapper depends on, and with community-only maintenance there is no guarantee a compatibility release follows quickly. Pinning your Axios version, or passing your own `axiosInstance`, keeps that decision in your hands. Note also that the build toolchain in `package.json` is old (Babel 6, Rollup 0.59, ava 0.25), which matters if you intend to fork and rebuild rather than consume the published bundle.

Who should still use Apisauce

Existing React Native and browser codebases that already call `api.get` and check `response.ok` have little reason to rip the wrapper out. The API is stable, the types ship with the package, and the response contract is the kind of thing that is annoying to change once call sites depend on it. Keeping it also keeps the monitor hooks that teams use for logging and timing.

New projects are a different answer, and the README gives it directly. Start with Axios and write the small wrapper you actually need. If you do adopt Apisauce anyway, verify two things before you commit: that the version you install is the one you expect from the release list, and that the `axiosInstance` option works with the Axios instance you already have configured, since that is where interceptors and the wrapper have to coexist.

Editorial conclusion

Use Apisauce if you already have it in a React Native or browser codebase and you want the ok/problem response shape without rewriting call sites, and accept that only community-submitted security patches are promised. Do not pick it for a new project, since the README itself says to use Axios directly and build your own wrapper instead. Before adopting anything, check the version you install against the 3.2.2 release and confirm that your axios instance is compatible with the axiosInstance option described in the README.

Frequently asked questions

Official sources

1. infinitered/apisauce on GitHub
2. Issues
3. License: MIT
4. README
5. Releases