OpenAI Python SDK Switches Default HTTP Client to HTTPX2

OpenAI has changed how its Python SDK, openai-python, handles HTTP communication. According to its migration guide, the package now uses HTTPX2 as the default client for both sync and async API calls, replacing HTTPX. Installing the openai package now pulls in HTTPX2 automatically, and httpx no longer comes along for the ride the way it used to.

To unpack that a bit: HTTPX is the tool a Python program uses to talk to a server over the internet, and certificate verification is the step that confirms the other side of that conversation is really OpenAI's server. Until now, that check ran against a certificate list bundled with a separate package called certifi. Going forward, it runs against whatever certificate store is already installed on the machine or server — the operating system's own trust store.

It's not just the name of the networking tool that changed. The standard used to validate certificates changed with it. The SDK used to check server certificates against the CA list that certifi ships with; HTTPX2 checks them against the operating system's trust store instead. And the SDK no longer installs certifi separately at all.

Why this change can cause trouble

The catch is that not every environment has that operating system certificate store properly set up. The guide warns that certificate verification can break in minimal container images missing system CA certificates, in corporate environments running TLS-inspection proxies that intercept internal traffic, and in deployments that have relied on a custom or modified certifi bundle. In other words, a server that's been running fine for ages, with no special configuration, could suddenly start throwing connection errors the moment the SDK gets reinstalled — even if nothing else about the code changed.

What developers should check right now

The guide's recommended fix is either to install the necessary CA certificates into the operating system's trust store directly, or to specify an explicit certificate bundle. Those settings also apply through environment variables when trust_env=True (the default), and developers can pass an ssl.SSLContext through the verify argument to set trust boundaries explicitly for a custom client.

A good chunk of existing code still works without changes. If you create an OpenAI or AsyncOpenAI client without specifying http_client yourself, API calls, response model parsing, streaming, authentication, retries, and numeric timeout settings all continue to work as before. The names DefaultHttpxClient and DefaultAsyncHttpxClient still work too — they just build an HTTPX2 client under the hood now. The guide recommends switching to DefaultHttpx2Client and DefaultAsyncHttpx2Client if you want the client type spelled out explicitly.

There are spots that do need attention, though. Custom authentication handlers or hooks now receive HTTPX2's request and response objects, so those classes need updating. And if your test suite uses a mocking library like RESPX, you'll need a version that can intercept HTTPX2 — the guide notes that existing httpx-only adapters can't intercept the SDK's new default client.

There's also a temporary workaround for projects that can't migrate right away. Installing httpx separately and explicitly injecting the legacy client lets existing HTTPX-based code keep running for now. But the guide is blunt about the limits: this path only works at runtime, passing static type checks requires workarounds like cast(Any, ...), and the support itself could be discontinued down the line.

Before and after, at a glance

Item	Before (HTTPX)	After (HTTPX2)
Default HTTP client	httpx	httpx2
Auto-installed?	Installed automatically with openai	Installed automatically with openai; httpx no longer auto-installed
Certificate trust standard	certifi CA bundle	Operating system trust store
DefaultHttpxClient behavior	Creates an HTTPX client	Name kept, but now creates an HTTPX2 client internally
Legacy support	Not applicable	Runtime-compatible path available via explicit install (may be discontinued)

Editor's take

This change doesn't have the flash of a new model launch or a pricing overhaul. But for developers actually running production services on top of the OpenAI API, it's the kind of risk that can matter just as much as a model update — maybe more, because it arrives quietly. Everyone notices when a model's name changes. Almost nobody notices when the HTTP client underneath gets swapped out, until a deployment starts failing for no obvious reason.

Put this next to OpenAI's recent price war move — cutting both input and output token prices for GPT-5.6 Luna by 80% — and you can see two fronts OpenAI is working at once. One is price competition against cheaper models coming out of China. The other is making sure developers can use the API with as little friction as possible. Changing the SDK's default networking layer and its certificate verification standard isn't glamorous work, but for any company calling the OpenAI API at scale, it goes straight to the question of whether deployments stay stable.

In practical terms, three things are worth checking before anything else. First, whether the container images you're running actually include system CA certificates. Second, whether any of your deployments depend on an internal TLS-inspection proxy or a custom certificate bundle. Third, if your test suite uses an HTTP mocking library like RESPX, whether that version is compatible with HTTPX2. Running through these three checks before installing or upgrading the openai package should cut down on the chance of getting blindsided by certificate errors on deployment day.

Since OpenAI has explicitly framed legacy HTTPX support as a migration aid rather than a permanent option, it's safe to assume that workaround will eventually disappear. It's probably worth starting to clean up your code around HTTPX2 now, rather than waiting until that day arrives.