HTTP Clients

17 min read

In Node you reach for fetch (built in since Node 18) or axios to call an API. In Rust the de facto choice is reqwest — a high-level, async, batteries-included HTTP client. This chapter maps fetch/axios patterns (GET/POST JSON, headers, query strings, a reusable client) onto reqwest, and explains where the low-level hyper crate fits in.

Quick Overview

reqwest is to Rust what axios is to Node: an ergonomic client with JSON support, a connection pool, timeouts, and a builder API. It is async by default and runs on the Tokio runtime, but also ships an optional blocking API for scripts and build tools. Like axios, you create one client and reuse it so connections (and TLS handshakes) are pooled across requests.

The current stable toolchain is Rust 1.96.0 on the 2024 edition, and cargo new selects it automatically. The examples here use reqwest 0.13, tokio 1.52, and serde 1.

TypeScript/JavaScript Example

A typical Node service that talks to a JSON API with axios: a shared client instance, a typed GET, a POST with a JSON body, and a request with custom headers and query parameters.

1
// npm install axios
2
import axios, { AxiosInstance } from "axios";
3

4
interface Todo {
5
  userId: number;
6
  id: number;
7
  title: string;
8
  completed: boolean;
9
}
10

11
interface NewPost {
12
  title: string;
13
  body: string;
14
  userId: number;
15
}
16

17
// Create ONE client and reuse it — connection keep-alive, shared config.
18
const client: AxiosInstance = axios.create({
19
  baseURL: "https://jsonplaceholder.typicode.com",
20
  timeout: 10_000,
21
  headers: { "User-Agent": "ts-to-rust-guide/1.0" },
22
});
23

24
async function main(): Promise<void> {
25
  // GET JSON — axios parses the body for you.
26
  const { data: todo } = await client.get<Todo>("/todos/1");
27
  console.log("GET ->", todo);
28

29
  // POST JSON — body is serialized, Content-Type set automatically.
30
  const newPost: NewPost = {
31
    title: "Learning Rust",
32
    body: "axios is familiar",
33
    userId: 1,
34
  };
35
  const { data: created } = await client.post("/posts", newPost);
36
  console.log("POST -> id =", created.id);
37

38
  // Headers + query params; axios throws on 4xx/5xx by default.
39
  const res = await client.get("/comments", {
40
    headers: { Accept: "application/json" },
41
    params: { postId: 1 },
42
  });
43
  console.log("status =", res.status);
44
}
45

46
main().catch((err) => {
47
  // axios bundles the response on the error object.
48
  console.error("request failed:", err.message);
49
  process.exit(1);
50
});

The same code with the built-in fetch is more manual — you call res.json() yourself, set Content-Type by hand, and check res.ok because fetch does not throw on 4xx/5xx. Keep that detail in mind; reqwest behaves like fetch here, not like axios.

Rust Equivalent

1
# Cargo.toml — or run:
2
#   cargo add reqwest --features json,query
3
#   cargo add tokio --features full
4
#   cargo add serde --features derive
5
[dependencies]
6
reqwest = { version = "0.13", features = ["json", "query"] }
7
tokio = { version = "1", features = ["full"] }
8
serde = { version = "1", features = ["derive"] }

1
use serde::{Deserialize, Serialize};
2
use std::time::Duration;
3

4
#[derive(Debug, Deserialize)]
5
struct Todo {
6
    id: u32,
7
    title: String,
8
    completed: bool,
9
}
10

11
#[derive(Debug, Serialize)]
12
struct NewPost {
13
    title: String,
14
    body: String,
15
    // JSON uses camelCase; Rust uses snake_case. serde renames the field.
16
    #[serde(rename = "userId")]
17
    user_id: u32,
18
}
19

20
#[derive(Debug, Deserialize)]
21
struct CreatedPost {
22
    id: u32,
23
    title: String,
24
}
25

26
#[tokio::main]
27
async fn main() -> Result<(), reqwest::Error> {
28
    // Create ONE client and reuse it: it owns the connection pool.
29
    let client = reqwest::Client::builder()
30
        .timeout(Duration::from_secs(10))
31
        .user_agent("ts-to-rust-guide/1.0")
32
        .build()?;
33

34
    // GET JSON: .json::<T>() deserializes the body for you.
35
    let todo: Todo = client
36
        .get("https://jsonplaceholder.typicode.com/todos/1")
37
        .send()
38
        .await?
39
        .json()
40
        .await?;
41
    println!("GET -> {todo:?}");
42

43
    // POST JSON: .json(&body) serializes and sets Content-Type.
44
    let new_post = NewPost {
45
        title: "Learning Rust".to_string(),
46
        body: "reqwest is great".to_string(),
47
        user_id: 1,
48
    };
49
    let created: CreatedPost = client
50
        .post("https://jsonplaceholder.typicode.com/posts")
51
        .json(&new_post)
52
        .send()
53
        .await?
54
        .json()
55
        .await?;
56
    println!("POST -> id={}, title={:?}", created.id, created.title);
57

58
    // Headers + query params + status handling.
59
    let resp = client
60
        .get("https://jsonplaceholder.typicode.com/comments")
61
        .header("Accept", "application/json")
62
        .query(&[("postId", "1")])
63
        .send()
64
        .await?;
65
    println!("status = {}", resp.status());
66
    let resp = resp.error_for_status()?; // turn 4xx/5xx into an Err
67
    let body = resp.text().await?;
68
    println!("body bytes = {}", body.len());
69

70
    Ok(())
71
}

Running this prints (real output):

1
GET -> Todo { id: 1, title: "delectus aut autem", completed: false }
2
POST -> id=101, title="Learning Rust"
3
status = 200 OK
4
body bytes = 1510

Detailed Explanation

Read the request chain as a sequence: build a request, send it, then read the response — each await marks a point where the task yields back to the runtime.

`reqwest::Client` and the builder

reqwest::Client::builder() returns a ClientBuilder. You set defaults — .timeout(...), .user_agent(...), .default_headers(...), redirect and connection-pool policy — then .build()? produces a Client. The ? propagates a reqwest::Error if, say, TLS fails to initialize.

Tip: Client is an Arc inside, so cloning it is cheap — it shares the same connection pool. Pass client.clone() into tasks freely; do not wrap it in another Arc.

`.get(url)` / `.post(url)` → `RequestBuilder`

These return a RequestBuilder you decorate before sending: .header(...), .query(...), .json(...), .bearer_auth(...), .basic_auth(...), .timeout(...) (per-request override). Nothing has been sent yet — this mirrors axios.create(...).get(...) building a config object.

`.send().await?` → `Response`

.send() returns a future; .await drives it to completion and ? unwraps the Result. Crucially, the future is lazy — unlike a JavaScript Promise, which starts running the moment you call axios.get(...), a reqwest future does nothing until you .await it (or hand it to the runtime via tokio::join!/tokio::spawn). Forgetting .await is the single most common reqwest mistake; the compiler catches it. See Common Pitfalls.

Reading the body: two `await`s

JSON decoding is itself async because the body streams in. So .json::<T>().await? is a second await: read the bytes, then deserialize with serde into your T. The chain client.get(...).send().await?.json().await? is the reqwest idiom for “GET and parse JSON,” equivalent to (await client.get<T>(url)).data in axios. Other readers: .text().await?, .bytes().await?, or .json::<serde_json::Value>().await? for untyped JSON.

`.query(&[("postId", "1")])`

This URL-encodes a Serialize value into the query string — pairs like &[("a", "1"), ("b", "2")], a HashMap, or your own #[derive(Serialize)] struct. It is the equivalent of axios’s params option. In reqwest 0.13 this lives behind an optional query feature (see pitfalls).

`.error_for_status()?`

By default reqwest does not treat a 404 or 500 as an error — like fetch, a completed HTTP exchange is a success even if the server says “Not Found.” Call .error_for_status() to convert any 4xx/5xx into an Err(reqwest::Error), recovering axios’s throw-on-non-2xx behavior. This is one place the fetch/axios analogy breaks down, so make the choice explicit.

Key Differences

Concern	axios / fetch (Node)	reqwest (Rust)
Install	`npm install axios` (fetch built in)	`cargo add reqwest --features json,query`
JSON parse	`res.data` (axios) / `await res.json()` (fetch)	`.json::<T>().await?` into a typed struct
JSON body	`client.post(url, obj)`	`.json(&obj)` (needs `json` feature)
Non-2xx	axios throws; fetch does not	does not by default; call `.error_for_status()`
Reuse	`axios.create(...)` instance	`reqwest::Client` (clone is cheap, pools connections)
Concurrency	`Promise.all([...])`	`tokio::join!` / `futures::future::try_join_all`
Laziness	Promise starts immediately	future is lazy until `.await`
Timeout	`timeout` option	`.timeout(Duration)` on client or request
Query string	`params: { ... }`	`.query(&[...])` (needs `query` feature)
Blocking	n/a (always async)	`reqwest::blocking` (opt-in feature)
TLS	OpenSSL/system, transparent	rustls by default (pure-Rust), or native-tls

A few differences worth internalizing:

Typed by default. axios returns any unless you annotate get<T>, and even then the type is erased — nothing checks the wire data matches. reqwest deserializes into a concrete struct, and a shape mismatch is a real runtime Err you must handle, not a silent undefined three lines later.
rustls, not OpenSSL. reqwest 0.13 uses the pure-Rust rustls stack by default, so there is no system OpenSSL to install — great for slim Docker images and cross-compilation. You can opt into native-tls if you need the OS trust store.
One runtime. reqwest’s async API needs a runtime (Tokio). The #[tokio::main] attribute starts one. There is no global event loop the way Node has one for free.

Common Pitfalls

Forgetting `.await` on `.send()`

A reqwest future does nothing until awaited. If you forget, you are holding a Future, not a Response, and method calls fail to resolve:

1
#[tokio::main]
2
async fn main() -> Result<(), reqwest::Error> {
3
    let client = reqwest::Client::new();
4
    let resp = client.get("https://example.com").send(); // missing .await
5
    let body = resp.json::<serde_json::Value>().await?;
6
    println!("{body:?}");
7
    Ok(())
8
}

The real compiler error:

1
error[E0599]: no method named `json` found for opaque type `impl Future<Output = Result<Response, reqwest::Error>>` in the current scope
2
 --> src/main.rs:5:21
3
  |
4
5 |     let body = resp.json::<serde_json::Value>().await?;
5
  |                     ^^^^ method not found in `impl Future<Output = Result<Response, reqwest::Error>>`

The phrase impl Future<Output = ...> is the tell: you forgot to .await the previous step. Add .await? after .send().

The `query` (or `json`) feature is not enabled

reqwest is feature-gated to keep builds lean. .json(...) needs the json feature and .query(...) needs the query feature; without them the methods simply do not exist:

1
error[E0599]: no method named `query` found for struct `RequestBuilder` in the current scope
2
  --> src/main.rs:61:10
3
   |
4
61 |         .query(&[("page", "2"), ("limit", "10")])
5
   |          ^^^^^ method not found in `RequestBuilder`

The fix is in Cargo.toml, not the code: cargo add reqwest --features json,query. This trips up Node developers because axios bundles everything; reqwest makes you pay only for what you use.

Expecting a 404 to be an error

1
// (fragment) assume `url: &str`, a `client: reqwest::Client`, and a `User` deserialize type.
2
// This does NOT return Err on a 404 — the request "succeeded".
3
let resp = client.get(url).send().await?;
4
let user: User = resp.json().await?; // may instead fail to decode an error body

Like fetch, reqwest only errors on transport problems (DNS, connection, timeout), not on HTTP status. Add .error_for_status()? after .send().await? to opt into axios-style behavior, or inspect resp.status() yourself.

Creating a new `Client` per request

1
// Anti-pattern: rebuilds the connection pool and re-handshakes TLS each call.
2
async fn fetch(url: &str) -> Result<String, reqwest::Error> {
3
    let client = reqwest::Client::new(); // new pool every time!
4
    client.get(url).send().await?.text().await
5
}

reqwest::Client::new() allocates a fresh connection pool. Build it once and share clones — exactly as you would create one axios instance, not one per call. The free function reqwest::get(url) is convenient for one-off scripts but also spins up a throwaway client, so avoid it in hot paths.

Calling the blocking client inside an async runtime

reqwest::blocking spins up its own internal Tokio runtime. Calling it from inside #[tokio::main] will panic, because the blocking client tries to create and drop that runtime inside the async one. The real message you see is:

1
thread 'main' panicked at .../tokio-1.52.3/src/runtime/blocking/shutdown.rs:51:21:
2
Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.

Use the async Client in async code; reserve reqwest::blocking for genuinely synchronous programs.

Best Practices

Build the client once, clone to share. Store a reqwest::Client in your app state (or behind a typed wrapper) and clone it into handlers and tasks. Cloning shares the pool.
Always set a timeout. The default has no overall timeout. Set .timeout(Duration::from_secs(...)) on the client (and override per request when needed) so a hung server cannot stall a task forever.
Deserialize into concrete types. Prefer #[derive(Deserialize)] structs over serde_json::Value; you get validation and autocomplete instead of stringly-typed lookups. Use #[serde(rename = "...")] or #[serde(rename_all = "camelCase")] to bridge JSON casing.
Call .error_for_status() when you want axios semantics. Be explicit about whether a non-2xx is an error in your domain.
Enable only the features you use. json, query, stream, gzip, brotli, cookies, multipart, blocking are all opt-in. Smaller feature sets mean faster builds and smaller binaries.
Run concurrent requests with tokio::join! or try_join_all. Sequential awaits are like awaiting Promises one at a time; batch them when they are independent.
Wrap errors with context in apps. Convert reqwest::Error into your own error type (or use anyhow with .context(...)) so failures say which request failed. See ../08-error-handling/README.md.

Real-World Example

A small, production-flavored typed API client: it owns one reusable reqwest::Client, sets a timeout and user agent, attaches context to errors with anyhow, and runs several requests concurrently. This is the shape you would expose as a service layer.

1
# cargo add reqwest --features json
2
# cargo add tokio --features full
3
# cargo add serde --features derive
4
# cargo add anyhow
5
[dependencies]
6
reqwest = { version = "0.13", features = ["json"] }
7
tokio = { version = "1", features = ["full"] }
8
serde = { version = "1", features = ["derive"] }
9
anyhow = "1"

1
use anyhow::{Context, Result};
2
use serde::Deserialize;
3
use std::time::Duration;
4

5
#[derive(Debug, Deserialize)]
6
struct User {
7
    id: u32,
8
    name: String,
9
    email: String,
10
}
11

12
/// A typed client that holds one reusable `reqwest::Client`.
13
#[derive(Clone)]
14
struct ApiClient {
15
    http: reqwest::Client,
16
    base_url: String,
17
}
18

19
impl ApiClient {
20
    fn new(base_url: impl Into<String>) -> Result<Self> {
21
        let http = reqwest::Client::builder()
22
            .timeout(Duration::from_secs(10))
23
            .user_agent(concat!(env!("CARGO_PKG_NAME"), "/", env!("CARGO_PKG_VERSION")))
24
            .build()
25
            .context("failed to build HTTP client")?;
26
        Ok(Self { http, base_url: base_url.into() })
27
    }
28

29
    async fn get_user(&self, id: u32) -> Result<User> {
30
        let url = format!("{}/users/{id}", self.base_url);
31
        let user = self
32
            .http
33
            .get(&url)
34
            .send()
35
            .await
36
            .with_context(|| format!("GET {url}"))?
37
            .error_for_status()
38
            .context("server returned an error status")?
39
            .json::<User>()
40
            .await
41
            .context("failed to decode User JSON")?;
42
        Ok(user)
43
    }
44
}
45

46
#[tokio::main]
47
async fn main() -> Result<()> {
48
    let api = ApiClient::new("https://jsonplaceholder.typicode.com")?;
49

50
    // Fire three independent requests concurrently and await them all.
51
    let (a, b, c) = tokio::join!(
52
        api.get_user(1),
53
        api.get_user(2),
54
        api.get_user(3),
55
    );
56
    for user in [a?, b?, c?] {
57
        println!("#{} {} <{}>", user.id, user.name, user.email);
58
    }
59

60
    // A 404 becomes an Err thanks to .error_for_status().
61
    match api.get_user(99_999).await {
62
        Ok(u) => println!("got {u:?}"),
63
        Err(e) => println!("expected error: {e:#}"),
64
    }
65

66
    Ok(())
67
}

Real output:

1
#1 Leanne Graham <Sincere@april.biz>
2
#2 Ervin Howell <Shanna@melissa.tv>
3
#3 Clementine Bauch <Nathan@yesenia.net>
4
expected error: server returned an error status: HTTP status client error (404 Not Found) for url (https://jsonplaceholder.typicode.com/users/99999)

Note: {e:#} prints the full anyhow error chain — the top-level context plus the underlying cause — which is why you see both “server returned an error status” and the reqwest detail.

Where hyper fits in

reqwest is built on top of hyper, the low-level HTTP library that also powers Axum and many other Rust web stacks (see ./web-frameworks.md). hyper gives you fine-grained control over the connection, the HTTP state machine, and bring-your-own connection pool — but you assemble URIs, bodies, and TLS yourself. For application code that just needs “call this JSON API,” reqwest is the right tool; reach for hyper only when you are building infrastructure (a proxy, a custom client with unusual pooling, or your own framework) where reqwest’s conveniences get in the way. Think of it as fetch/axios (reqwest) versus Node’s raw http/https modules (hyper).

Shared default headers

When every request needs the same headers (an Authorization token, an Accept), set them once with .default_headers(...) instead of repeating .header(...):

1
use reqwest::header::{HeaderMap, HeaderValue, ACCEPT, AUTHORIZATION};
2

3
#[tokio::main]
4
async fn main() -> Result<(), reqwest::Error> {
5
    let mut headers = HeaderMap::new();
6
    headers.insert(ACCEPT, HeaderValue::from_static("application/json"));
7
    headers.insert(AUTHORIZATION, HeaderValue::from_static("Bearer my-token"));
8

9
    let client = reqwest::Client::builder()
10
        .default_headers(headers)
11
        .build()?;
12

13
    let status = client
14
        .get("https://jsonplaceholder.typicode.com/todos/1")
15
        .send()
16
        .await?
17
        .status();
18
    println!("status with default headers = {status}");
19
    Ok(())
20
}

Real output: status with default headers = 200 OK. For a single per-request token, .bearer_auth("my-token") on the RequestBuilder is shorter.

Exercises

Exercise 1: Typed GET with query and auth

Difficulty: Beginner

Objective: Fetch a filtered list from a JSON API into a typed Vec, sending a query parameter and an Authorization header.

Instructions: Using reqwest with the json and query features, GET https://jsonplaceholder.typicode.com/posts, filtered to userId=1 via .query(...), with an Authorization: Bearer demo-token header. Deserialize the body into a Vec<Post> where Post has id: u32 and title: String. Call .error_for_status() before decoding, then print how many posts came back and the first title.

Solution

1
# cargo add reqwest --features json,query
2
# cargo add tokio --features full
3
# cargo add serde --features derive
4
# cargo add anyhow
5
[dependencies]
6
reqwest = { version = "0.13", features = ["json", "query"] }
7
tokio = { version = "1", features = ["full"] }
8
serde = { version = "1", features = ["derive"] }
9
anyhow = "1"

1
use anyhow::Result;
2
use serde::Deserialize;
3

4
#[derive(Debug, Deserialize)]
5
struct Post {
6
    id: u32,
7
    title: String,
8
}
9

10
#[tokio::main]
11
async fn main() -> Result<()> {
12
    let client = reqwest::Client::new();
13

14
    let posts: Vec<Post> = client
15
        .get("https://jsonplaceholder.typicode.com/posts")
16
        .query(&[("userId", "1")])
17
        .header(reqwest::header::AUTHORIZATION, "Bearer demo-token")
18
        .send()
19
        .await?
20
        .error_for_status()?
21
        .json()
22
        .await?;
23

24
    println!("user 1 has {} posts", posts.len());
25
    println!("first: {:?}", posts.first());
26
    Ok(())
27
}

Real output:

1
user 1 has 10 posts
2
first: Some(Post { id: 1, title: "sunt aut facere repellat provident occaecati excepturi optio reprehenderit" })

Exercise 2: POST JSON and read the created resource

Difficulty: Intermediate

Objective: Serialize a struct as a JSON body, POST it, and deserialize the response into a different type.

Instructions: Define NewComment { name: String, body: String, post_id: u32 } with #[serde(rename = "postId")] on the id field. POST it to https://jsonplaceholder.typicode.com/comments with .json(&body). Deserialize the response into CreatedComment { id: u32 } and print the new id. Reuse a single Client built with a 10-second timeout.

Solution

1
use anyhow::Result;
2
use serde::{Deserialize, Serialize};
3
use std::time::Duration;
4

5
#[derive(Debug, Serialize)]
6
struct NewComment {
7
    name: String,
8
    body: String,
9
    #[serde(rename = "postId")]
10
    post_id: u32,
11
}
12

13
#[derive(Debug, Deserialize)]
14
struct CreatedComment {
15
    id: u32,
16
}
17

18
#[tokio::main]
19
async fn main() -> Result<()> {
20
    let client = reqwest::Client::builder()
21
        .timeout(Duration::from_secs(10))
22
        .build()?;
23

24
    let new_comment = NewComment {
25
        name: "reqwest reader".to_string(),
26
        body: "Great chapter!".to_string(),
27
        post_id: 1,
28
    };
29

30
    let created: CreatedComment = client
31
        .post("https://jsonplaceholder.typicode.com/comments")
32
        .json(&new_comment)
33
        .send()
34
        .await?
35
        .error_for_status()?
36
        .json()
37
        .await?;
38

39
    println!("created comment id = {}", created.id);
40
    Ok(())
41
}

The placeholder API echoes back a newly assigned id (it prints created comment id = 501). The point is that the request body is serialized from your struct and the response is parsed into a different one — strongly typed on both ends.

Exercise 3: Concurrent fetch with graceful failure

Difficulty: Advanced

Objective: Fetch several resources concurrently and collect results, distinguishing successes from failures instead of aborting on the first error.

Instructions: Given a list of user ids [1, 2, 99999, 3], fetch https://jsonplaceholder.typicode.com/users/{id} for each concurrently. Use .error_for_status() so a 404 becomes an Err. Collect the outcomes so that the missing user (99999) does not abort the others; print each success and each failure. Hint: spawn the futures, collect them into a Vec, and await each, matching on the Result rather than using ?.

Solution

1
use serde::Deserialize;
2

3
#[derive(Debug, Deserialize)]
4
struct User {
5
    id: u32,
6
    name: String,
7
}
8

9
async fn get_user(client: &reqwest::Client, id: u32) -> Result<User, reqwest::Error> {
10
    client
11
        .get(format!("https://jsonplaceholder.typicode.com/users/{id}"))
12
        .send()
13
        .await?
14
        .error_for_status()?
15
        .json::<User>()
16
        .await
17
}
18

19
#[tokio::main]
20
async fn main() {
21
    let client = reqwest::Client::new();
22
    let ids = [1u32, 2, 99_999, 3];
23

24
    // Build one future per id, then await them all concurrently.
25
    let futures = ids.iter().map(|&id| {
26
        let client = client.clone();
27
        async move { (id, get_user(&client, id).await) }
28
    });
29
    let results = futures::future::join_all(futures).await;
30

31
    for (id, result) in results {
32
        match result {
33
            Ok(user) => println!("ok  #{} {}", user.id, user.name),
34
            Err(e) => println!("err #{id}: {}", e.status()
35
                .map(|s| s.to_string())
36
                .unwrap_or_else(|| e.to_string())),
37
        }
38
    }
39
}

Add the futures crate: cargo add futures. join_all runs every future concurrently and returns a Vec of results in order, so one 404 cannot abort the rest. The successful users print with their names; user 99999 prints its 404 Not Found status. (For a fixed, small number of requests you could use tokio::join! instead; join_all shines when the count is dynamic.)

HTTP Clients

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

reqwest::Client and the builder

.get(url) / .post(url) → RequestBuilder

.send().await? → Response

Reading the body: two awaits

.query(&[("postId", "1")])

.error_for_status()?

Key Differences

Common Pitfalls

Forgetting .await on .send()

The query (or json) feature is not enabled

Expecting a 404 to be an error

Creating a new Client per request

Calling the blocking client inside an async runtime

Best Practices

Real-World Example

Where hyper fits in

Shared default headers

Further Reading

Exercises

Exercise 1: Typed GET with query and auth

Exercise 2: POST JSON and read the created resource

Exercise 3: Concurrent fetch with graceful failure

`reqwest::Client` and the builder

`.get(url)` / `.post(url)` → `RequestBuilder`

`.send().await?` → `Response`

Reading the body: two `await`s

`.query(&[("postId", "1")])`

`.error_for_status()?`

Forgetting `.await` on `.send()`

The `query` (or `json`) feature is not enabled

Creating a new `Client` per request