How would you deal with a blocking library call inside an async FastAPI endpoint?

Move it off the event loop. Wrap the blocking call in asyncio.to_thread, or use run_in_executor with a thread pool, so the loop stays free to serve other requests. If the work is CPU bound, send it to a process pool or a background worker such as Celery instead. Left inline, one slow call stalls every other request on that worker.

The reason it matters is that asyncio is cooperative and single threaded, so a coroutine keeps the loop until it awaits something. A blocking driver call sitting in an async handler freezes every other in flight request on that worker, and under low traffic you will never notice. Cheapest fix in FastAPI is to define the endpoint with plain def rather than async def, and the framework runs it in its threadpool for you. If I need it inside an async function, asyncio.to_thread wraps the call and awaits the result. Where I am careful is the thread pool size, because the default is small and a slow dependency will queue behind it, so I size it against the concurrency I expect and add a timeout. For anything CPU heavy, threads do not help under the default build, so it goes to a process pool or out to a Celery worker. We caught one of these with a legacy SOAP client that took eight seconds, and p99 latency across an entire service was tracking that one call.