Calling HTTP APIs from Python CLIs

A large share of internal CLIs are front ends to a web API: list the deployments, trigger a build, fetch the logs, download the dataset. They start as twenty lines around requests.get() and grow into tools a whole team depends on. Along the way the same problems appear in roughly the same order. A command hangs forever because the server stopped responding mid-request. A 502 during a deploy aborts a script that would have succeeded a second later. A listing command silently shows only the first 100 results. Someone pastes a long-lived token into a config file. A two-gigabyte download fails at 95% and starts again from zero.

This topic covers the patterns that make an API-backed CLI dependable: one client module over a configured httpx session, explicit timeouts, retries that are safe and polite, pagination that streams instead of collecting, a login flow that never asks for a password, and downloads that show progress and resume. It is part of the CLI Runtime & Systems Integration section; the concurrency side — many requests at once — lives in concurrency and async in Python CLIs, and token storage lives in secrets and credentials.

TL;DR

• Use one httpx.Client per run, configured once with a base URL, auth, timeouts, a User-Agent and retries. Keep it in one module; commands never build URLs.
• Always set timeouts. httpx defaults to five seconds for everything, which is too short for some reads and says nothing about total duration. Choose values on purpose and add an overall deadline for long operations.
• Retry only what is safe to retry — connection failures, 429 and 5xx responses on idempotent requests — with capped exponential backoff and jitter, and honour Retry-After.
• Paginate with a generator that yields items, so --limit stops fetching early and --all streams without holding everything in memory.
• Log in with the OAuth device flow where the API supports it, and store tokens in the system keychain, not a dot-file.
• Stream downloads to a .part file, verify, then rename; resume with a Range request when interrupted.

Why httpx, and why one client

requests is still everywhere and still works. For new CLIs, httpx is the better default: it has a nearly identical API, supports HTTP/2, has a clean timeout model, provides MockTransport for tests without extra libraries, and offers the same interface in synchronous and async forms, so moving a command to concurrent requests later does not mean switching libraries.

Whichever library you use, create one client per invocation rather than calling module-level httpx.get() for each request. A client holds a connection pool: the first request pays for DNS, TCP and the TLS handshake, and subsequent requests to the same host reuse that connection. For a command that makes twenty requests, that is often the difference between two seconds and six.

The client sits in the middle of a three-layer structure. Commands parse arguments and render output. An API client module — your code — exposes functions like list_projects() and get_build(build_id) that return typed objects. Underneath, a configured httpx.Client handles transport concerns. Commands never see URLs or status codes; the API module never prints. That separation is what makes each part testable, and it mirrors the thin-command-layer advice in how to structure a large Python CLI project.

# src/mytool/api.py
from __future__ import annotations

from dataclasses import dataclass
from importlib.metadata import version

import httpx


@dataclass(frozen=True)
class Project:
    name: str
    owner: str
    builds: int


class ApiError(Exception):
    def __init__(self, message: str, exit_code: int = 1) -> None:
        super().__init__(message)
        self.exit_code = exit_code


def make_client(base_url: str, token: str | None) -> httpx.Client:
    headers = {"User-Agent": f"mytool/{version('mytool')}", "Accept": "application/json"}
    if token:
        headers["Authorization"] = f"Bearer {token}"
    return httpx.Client(
        base_url=base_url,
        headers=headers,
        timeout=httpx.Timeout(30.0, connect=5.0),
        transport=httpx.HTTPTransport(retries=2),   # connection failures only
        follow_redirects=True,
    )


def list_projects(client: httpx.Client) -> list[Project]:
    response = client.get("/projects")
    if response.status_code == 401:
        raise ApiError("not logged in — run: mytool login", exit_code=4)
    response.raise_for_status()
    return [Project(p["name"], p["owner"], p["build_count"]) for p in response.json()]

The User-Agent with your tool's version is a small courtesy with a large payoff: when the API team sees a spike of errors, they can tell which client and which release is responsible. The version itself should come from package metadata, as described in exposing version info and build metadata. Building an API client CLI with httpx takes this module all the way to a finished command with tables, JSON output and tests.

Timeouts are not optional

A request without a meaningful timeout is a potential hang. A server can accept the connection and then never respond; a load balancer can hold a request open for minutes; a corporate proxy can stall silently. The user sees a frozen terminal and eventually presses Ctrl+C, which is the least helpful way to learn that the API is down.

httpx separates four timeouts, and each guards against a different stall:

The defaults are five seconds for each. For a CLI, a short connect timeout (a few seconds) is right: if the server cannot even complete a TLS handshake, waiting longer rarely helps, and the user deserves to know quickly. The read timeout should reflect the slowest legitimate endpoint — a report generation call might need sixty seconds. Note that the read timeout limits the gap between bytes, not the total: a server trickling one byte every twenty seconds never trips it. For operations with a real time budget, wrap them in an overall deadline and expose it as a --timeout option.

When a timeout fires, httpx raises httpx.ConnectTimeout or httpx.ReadTimeout (both subclasses of httpx.TimeoutException). Catch them at the API layer and turn them into a message that names the host and the limit: "api.example.com did not respond within 30s — check the service status or retry with --timeout 120."

Failing well: status codes and retries

Not all failures are equal, and the right response depends on who caused them.

Client errors (4xx) mean the request was wrong: bad credentials, a missing resource, invalid input. Retrying will produce the same answer, so report it — ideally using the server's own error message, which for a 422 usually says exactly which field was invalid — and exit non-zero. Map 401 and 403 to a message that tells the user how to authenticate.

Server errors (5xx) and rate limits (429) mean the server is having trouble right now. These are worth retrying, a few times, with increasing delays. Network errors — DNS failures, refused connections, resets — are also worth a retry, and after the final attempt deserve a message that mentions the usual suspects: VPN, proxy settings, DNS.

The retry policy itself has subtleties that are easy to get wrong. Retrying a POST after a read timeout can create a duplicate, because the server may have processed the first attempt. Retrying immediately and in lockstep with every other client makes an overloaded server worse. And ignoring the server's Retry-After header wastes both sides' time. Retries and backoff for CLI HTTP calls builds a small retry wrapper that handles all three, with a deterministic test suite.

Lists that do not fit in one response

Every serious API paginates. The bug that ships most often in API-backed CLIs is not an error at all: a listing command that fetches the first page and presents it as the whole answer. The user filters for failed builds, sees none, and concludes everything is fine — because the failures were on page two.

The robust pattern is a generator in the API module that follows the API's pagination scheme — page numbers, cursors or Link headers — and yields individual items:

from collections.abc import Iterator
from typing import Any

import httpx


def iter_builds(client: httpx.Client, project: str) -> Iterator[dict[str, Any]]:
    params: dict[str, Any] = {"project": project, "per_page": 100}
    while True:
        response = client.get("/builds", params=params)
        response.raise_for_status()
        body = response.json()
        yield from body["items"]
        cursor = body.get("next_cursor")
        if not cursor:
            return
        params["cursor"] = cursor

Because it is lazy, the command decides how much to fetch: itertools.islice(iter_builds(...), limit) stops after the first page when the user asked for twenty items, while --all walks every page and can stream results as they arrive. Paginating API results in a CLI covers the three pagination styles, sensible defaults for --limit, and streaming NDJSON output for scripts.

Authentication without passwords

A CLI that asks for a username and password is asking users to type their most sensitive credential into a program they cannot inspect, and it breaks as soon as the organisation enables single sign-on or multi-factor authentication. Two better options cover almost every case:

• Personal access tokens that the user creates in the web UI and passes via an environment variable or a login --token command. Simple, scriptable, and ideal for CI.
• The OAuth 2.0 device authorization flow (RFC 8628), which GitHub, Microsoft, Google and most identity providers support. The CLI displays a short code and a URL; the user approves in any browser, on any device, using whatever SSO and MFA their organisation requires; the CLI receives tokens. No password ever touches your program.

The device flow is the one gh auth login and az login --use-device-code use, and it is less work to implement than most people expect — two endpoints and a polling loop. OAuth device flow login for CLIs implements it with httpx, handles every polling response, and stores the resulting tokens with keyring.

Big responses: downloads

Downloading a large file is its own problem. response.content loads the whole body into memory; writing straight to the destination leaves a truncated file if the connection drops; and a silent two-minute download looks exactly like a hang. The pattern that fixes all three streams the body in chunks with client.stream("GET", url), writes to a .part file beside the destination while updating a progress bar, verifies size and checksum, and renames into place — the same shape as an atomic write. If the connection drops, a later run can send a Range header to fetch only the missing bytes. Downloading files with progress in Python puts it together with a Rich progress bar.

Testing API-backed commands

Tests for an API client should never hit the network. httpx ships httpx.MockTransport, which routes requests to a Python function you write, so you can return canned responses, simulate failures and count calls without any extra dependency:

import httpx

from mytool.api import ApiError, list_projects


def make_test_client(handler) -> httpx.Client:
    return httpx.Client(base_url="https://api.test", transport=httpx.MockTransport(handler))


def test_list_projects():
    def handler(request: httpx.Request) -> httpx.Response:
        assert request.url.path == "/projects"
        return httpx.Response(200, json=[{"name": "web", "owner": "ana", "build_count": 3}])

    projects = list_projects(make_test_client(handler))
    assert [p.name for p in projects] == ["web"]


def test_unauthorised_is_a_clear_error():
    client = make_test_client(lambda request: httpx.Response(401))
    try:
        list_projects(client)
    except ApiError as exc:
        assert exc.exit_code == 4
        assert "mytool login" in str(exc)
    else:
        raise AssertionError("expected ApiError")

Because commands receive the client rather than creating it deep inside, a test can build the command's context with a mock-transport client and run the command end to end through CliRunner. That pattern — construct collaborators at the edge, pass them in — is covered in dependency injection patterns for CLI commands. For recording real responses once and replaying them, libraries such as respx or pytest-recording build on the same transport hook.

Proxies, certificates and corporate networks

Internal tools run inside corporate networks more often than anywhere else, and those networks are where HTTP clients fail in confusing ways. Three things are worth handling deliberately.

Proxies. httpx honours HTTP_PROXY, HTTPS_PROXY, ALL_PROXY and NO_PROXY from the environment by default (trust_env=True). Keep that default — users behind a proxy have already configured those variables for every other tool — and mention them in your connection-error message, because "cannot connect" behind a misconfigured proxy is otherwise baffling.

Custom certificate authorities. Many companies intercept TLS with their own root certificate. Requests then fail with CERTIFICATE_VERIFY_FAILED, and the tempting fix is verify=False, which disables the protection entirely. Instead, let users point at their bundle: honour SSL_CERT_FILE (httpx does, through trust_env), and consider the truststore package, which makes Python use the operating system's certificate store — the one IT has already configured.

Base URLs per environment. Staging and production usually differ only in the host. Make the base URL a setting with the normal precedence — --api-url flag, MYTOOL_API_URL variable, config file, built-in default — so one binary works everywhere without code changes. The mechanics are in config precedence: flags, env, files and defaults.

Key takeaways

• Put every HTTP call behind an API client module that returns typed objects and raises one error type; commands only render.
• Create one configured httpx.Client per run for connection reuse, a proper User-Agent and consistent auth.
• Choose connect and read timeouts deliberately and add an overall deadline where users need one.
• Report 4xx errors clearly; retry 429, 5xx and network errors with capped, jittered backoff, and only for idempotent requests.
• Paginate with generators so limits stop early and "all" streams.
• Prefer device-flow login or personal access tokens over passwords; keep tokens in the keychain.
• Test with httpx.MockTransport — no network, no extra dependencies.

Frequently asked questions

Related

• Up: CLI Runtime & Systems Integration
• Down: Building an API client CLI with httpx
• Down: Retries and backoff for CLI HTTP calls
• Down: Paginating API results in a CLI
• Down: OAuth device flow login for CLIs
• Down: Downloading files with progress in Python
• Sideways: Concurrency and async in Python CLIs
• Sideways: Secrets and credentials in Python CLIs