Skip to main content

Performance

If your application sends hundreds of requests per second, follow these recommendations.

Reuse clients

Make sure to reuse a client instance when sending multiple requests. Setting up a new client involves the overhead of starting new connections and TLS handshakes.

Ensure zstd is available

The clients compress request bodies of 1 KiB or more with zstd, which reduces upload size and time, especially for large states. Make sure zstd is installed on Python versions earlier than 3.14:
Compression can be configured or disabled via the compression client constructor argument.

Use aiohttp for async code

For async code at high request rates, pass an aiohttp-based HTTP client from httpx-aiohttp:

Create a client per thread

TypeSafeClient can be shared between threads, but under heavy load its connection pool becomes the bottleneck. Create one client per thread and reuse it for every request that thread sends.
Example

HTTP/2

The clients use HTTP/1.1 by default and can switch to HTTP/2:
  • HTTP/1.1 sends one request at a time per connection and opens a connection for each concurrent request, up to the connection limit. Concurrency scales with the number of connections, at the cost of a TLS handshake for each new one.
  • HTTP/2 multiplexes every request from one client over a single connection. It needs only one handshake and one socket, but that connection caps the client’s throughput.
Keep the default HTTP/1.1 for high request rates. Use HTTP/2 for low to moderate concurrency when you want fewer connections, for example behind a proxy or firewall that limits them. To enable HTTP/2, install the 'typesafe-sdk[http2]' extra and pass an HTTP/2 client. See the httpx2 HTTP/2 guide for details.

Keep a connection limit

The default clients open at most 100 connections and keep all of them open for 30 seconds while idle, so bursts reuse connections instead of opening new ones. Make sure to set appropriate limits when providing your own http_client.
Example

Logging

The SDK logs to the typesafe_sdk logger. Configure it according to standard logging guide:
Or set TYPESAFE_LOG_LEVEL to one of debug, info, warning, error, or off before importing the SDK. info logs one summary line per request; debug also logs request and response headers and bodies. Secret headers — authorization, API keys, cookies, and any header whose name contains token or secret — are redacted from log output. Request and response bodies are not redacted.

Forward compatibility

The SDK keeps working as the TypeSafe API evolves, so you can adopt new API features before an SDK release adds first-class support for them.

Extra request fields

Send additional API request fields with extra_body. The beam_width field below is illustrative; only send fields supported by the API.

Raw question dictionaries

TipUnknown fields are a forward-compatibility escape hatch. Ignore their type-checking errors and prefer upgrading the SDK instead.

Unknown answer kinds

The SDK logs a warning and skips unrecognized answer kinds. Use raw_http_response to inspect the complete API response, including those answers:

Unknown response fields

Unknown extra fields on recognized responses are ignored.