Fuel: a coroutine-first HTTP client for Kotlin and Android

What Fuel replaces in a Kotlin codebase

Raw HttpURLConnection plus a thread pool, or OkHttp plus hand-written callback plumbing, is the usual starting point for an Android or JVM service that talks to a REST endpoint. Fuel targets that gap. The README calls it "the easiest HTTP networking library for Kotlin backed by Kotlinx Coroutines", and the quick start shows the shape of that claim: one suspend call returns a body you can read as a string.

The audience is narrower than "anyone doing HTTP in Kotlin". Fuel assumes Kotlin 2.0, Java 8 bytecode, and on Android a minimum of API level 5. If your module is still Java, or you need a client that also runs in the browser, the repository layout points elsewhere: the samples directory contains httpbin-wasm and mockbin-native, so WebAssembly and native targets exist, but the README's own examples are JVM and Apple only.

How the coroutine API and the platform engines fit together

Fuel is a thin layer, not a new transport. On the JVM it hands configuration to OkHttpClient; on Apple platforms it takes an NSURLSessionConfiguration. That split is visible in the custom configuration section of the README, where the same FuelBuilder call is fed a different config object per platform.

The data flow is: build a Fuel instance (or use the default one), issue a suspend request, receive a response whose body can be read as a string or, with an added module, deserialized. The repository carries separate Gradle modules for that last step: fuel-moshi-jvm, fuel-kotlinx-serialization, fuel-jackson-jvm and fuel-forge-jvm. Each is opt-in, which keeps the core artifact free of a serialization dependency.

The README also states plainly that the library throws exceptions and that production apps must catch them. There is no Result wrapper in the quick start, so error handling is your code, not the library's.

Installing Fuel and making a first request

The README gives a single Gradle dependency for the release version, published under the group com.github.kittinunf.fuel. Add it to the module that performs the network calls.

implementation("com.github.kittinunf.fuel:fuel:3.0.0-alpha04")

The quick start then shows the shortest form, a suspend function called inside runBlocking for a script or test. In an Android app you would call it from a coroutine scope instead.

runBlocking {
    val string: String = Fuel.get("https://publicobject.com/helloworld.txt").body.string()
    println(string)
}

The same request can be written as an extension on the URL string, which reads well when the URL is already a variable.

runBlocking {
    val string: String = "https://publicobject.com/helloworld.txt".httpGet().body.string()
    println(string)
}

When you need a configured client, build one with FuelBuilder and pass a request lambda. This is the form to use if you plan to set timeouts or an interceptor, because the builder is where the OkHttpClient goes.

runBlocking {
    val fuel = FuelBuilder().build()
    val string: String = fuel.get(request = { url = "https://publicobject.com/helloworld.txt" }).body.string()
    println(string)
}

The README does not document response status handling, retries or timeouts in the quick start, so expect to read the linked documentation site for anything beyond a successful body read.

The 2.x and 3.x split is the real adoption risk

The migration note is short and consequential. From 3.x onward, main is the base branch; the old 2.x code sits on a branch named 2.x. The newest published version in the release list is 3.0.0-alpha04 from 2024-10-28, preceded by 3.0.0-alpha03 and 3.0.0-alpha02 earlier that year. That is an alpha line, not a stable one.

The README does not document a migration guide from 2.x to 3.x, does not list breaking changes, and does not say when a stable 3.0.0 is expected. Anyone already on 2.x has to read both branches themselves. Anyone starting fresh has to decide whether to build on an alpha artifact or on the older branch the README calls "the old version".

A second limitation is the exception model. The README says exceptions are thrown and must be caught in production. There is no built-in retry, no circuit breaker and no response type that forces you to handle failure, so a request that fails at the socket level surfaces as a thrown exception in whatever coroutine called it.

Fuel against Ktor Client, and when OkHttp alone is enough

Ktor Client is the comparison most Kotlin developers reach for. Both are coroutine-based, but they differ in where the abstraction lives. Fuel delegates to an existing engine: OkHttp on the JVM, NSURLSession on Apple. Ktor ships its own engine abstraction with separate artifacts per engine (CIO, OkHttp, Darwin, and others) and a plugin pipeline for content negotiation, auth and logging.

That difference decides the choice. If you already tune OkHttp, Fuel lets you keep those settings and adds a compact request API on top. If you want one configuration model across JVM, Android, iOS and JavaScript, Ktor's engine artifacts are the more direct fit, at the cost of a larger dependency surface. If your app makes two calls to one endpoint, neither library earns its place: OkHttp's own call API, or even HttpURLConnection, does the job with no extra artifact to keep current.

Maintenance, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-08-31, so commits are still landing. That is not the same as a stable release: the release list shows the newest tag as 3.0.0-alpha04 from 2024-10-28, and the README continues to advertise that alpha as the download. Renovate is configured in the repository, which suggests dependency updates are automated.

Upgrade cost concentrates in two places. First, the alpha version string in your build file: moving to a stable 3.0.0 will mean re-reading the changelog, which the README does not summarize. Second, R8 and Proguard. The README states Fuel is compatible with R8 out of the box with no extra rules, but if you use Proguard you may need rules for Coroutines, OkHttp and Okio, and additional rules for Serialization, Moshi or Moshi-Kotlin depending on which modules you pull in. Those rules are your maintenance burden, not the library's.

The licence is MIT, which permits commercial and closed-source use and requires preserving the copyright notice and permission text. That is a description of the licence, not legal advice; check how your organisation handles third-party notices.

Editorial conclusion

Adopt Fuel when your project is Kotlin-first, you want suspend functions in one line and you accept that the current download is 3.0.0-alpha04 while the 2.x line lives on a separate branch. Do not adopt it if you need a stable 3.x artifact, a documented migration path from 2.x, or a client whose engine you configure once for every target. Before writing code, confirm which branch the documentation at fuel.gitbook.io describes, whether the modules you need (fuel-moshi, fuel-kotlinx-serialization, fuel-jackson, fuel-forge) are published at the version you pin, and how your R8 or Proguard setup handles the coroutine and OkHttp rules the README points to.

Frequently asked questions

Official sources

1. kittinunf/fuel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases