Skip to main content
The Python SDK exports a single, synchronous Devhelm client built on httpx.Client. There’s no AsyncDevhelm as of v1.3.0 — but because httpx releases the GIL for I/O, the sync client parallelizes well from a thread pool, which covers nearly every concurrent workload.
A native async client (AsyncDevhelm on httpx.AsyncClient) is on the roadmap. If you need true asyncio integration, file a request at github.com/devhelmhq/sdk-python/issues — until then, the patterns below cover essentially every concurrent workload.

When to use concurrency

Pattern 1: Thread pool

concurrent.futures.ThreadPoolExecutor is the simplest way to parallelize SDK calls. Set max_workers to a modest number (8–16) to avoid hitting API rate limits.
Devhelm is safe to share across threads — it wraps a single httpx.Client with a connection pool.

Pattern 2: asyncio.to_thread from async code

Inside async def handlers (FastAPI, Starlette, aiohttp, etc.), wrap each call in asyncio.to_thread to keep the event loop free:
Each call runs on the default thread executor, so concurrency scales with the executor’s thread count (defaults to min(32, os.cpu_count() + 4)).

Bulk creates with error isolation

Rate-limiting tips

  • Cap max_workers to 8–16 by default. Higher concurrency rarely improves throughput against a rate-limited API.
  • Catch DevhelmRateLimitError and back off with exponential delay (the exception carries status, code, and request_id — there’s no retry_after attribute; see error handling).
  • Reuse a single Devhelm instance across threads — its connection pool amortizes TLS handshakes.

Next steps

Client reference

Full method reference for all resources.

Error handling

Exception types and retry patterns.