You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Implement async HTTP client wrapper using httpx #8
An async counterpart to the sync client using httpx.AsyncClient, enabling use in async frameworks like FastAPI, Starlette, and Django async views. It should share the same configuration and interface as the sync client so resource methods can delegate to either with minimal branching.
Proposed Steps
Add _AsyncHTTPClient to http_client.py, mirroring the sync interface with async def request(...).
Accept the same constructor arguments as _SyncHTTPClient.
Use async with httpx.AsyncClient(...) as client lifecycle management.
Extract a shared _build_request(method, path, params, json) helper used by both sync and async versions.
Acceptance Criteria
await client.request("GET", "/payments") returns the same response shape as the sync version.
The async client can be used in a pytest-asyncio test without event loop conflicts.
Closing the async client (via aclose()) is properly awaited.
Sync and async clients share URL-building and header logic without duplication.
I have experience building API clients, asynchronous applications, and automated testing. After reviewing the requirements, I understand that the goal is to introduce an asynchronous client implementation that mirrors the existing synchronous interface while sharing as much request-building logic as possible.
My approach would be to:
Implement an async HTTP client that matches the behavior and interface of the existing sync client.
Extract shared request construction logic to avoid duplication between sync and async implementations.
Ensure consistent URL building, header handling, and response shapes across both clients.
Add proper async lifecycle management, including support for clean client shutdown.
Add test coverage for async usage scenarios and verify compatibility with async test environments.
Ensure the implementation remains backward compatible with existing consumers.
I'll make sure the solution is well-tested, maintainable, and aligned with the project's existing architecture.
Please assign this issue to me if it is available. Thank you!
Hi, i applied for the sync client issue as well, and would love to complete both. This one bothers on the asynchronous nature of handling client connections, an async counterpart to the sync client using httpx.AsyncClient, which enables use in async frameworks like FastAPI, Starlette, and Django async views. It would share the same configuration and interface as the sync client, so resource methods can delegate to either with minimal branching. I'll add _AsyncHTTPClient to http_client.py, mirroring the sync interface with async def request(...).
Also accepting the same constructor arguments as _SyncHTTPClient.
Using async with httpx.AsyncClient(...) as client lifecycle management. And i'll ensure the acceptance criteria are met properly.
Activity
fathiaoyinloye commentedon Jun 20, 2026
I'd like to work on this issue.
I have experience building API clients, asynchronous applications, and automated testing. After reviewing the requirements, I understand that the goal is to introduce an asynchronous client implementation that mirrors the existing synchronous interface while sharing as much request-building logic as possible.
My approach would be to:
I'll make sure the solution is well-tested, maintainable, and aligned with the project's existing architecture.
Please assign this issue to me if it is available. Thank you!
grantfox-oss commentedon Jun 24, 2026
🦊 GrantFox — @fathiaoyinloye has been assigned to this issue as part of the Official Campaign campaign!
Next steps:
Closes #8)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Jul 24, 2026
🦊 GrantFox — @fathiaoyinloye has been assigned to this issue as part of the Official Campaign | FWC26 campaign!
Next steps:
Closes #8)Good luck! Track your progress on GrantFox.
DioChuks commentedon Aug 18, 2026
Hi, i applied for the sync client issue as well, and would love to complete both. This one bothers on the asynchronous nature of handling client connections, an async counterpart to the sync client using
httpx.AsyncClient, which enables use in async frameworks like FastAPI, Starlette, and Django async views. It would share the same configuration and interface as the sync client, so resource methods can delegate to either with minimal branching. I'll add_AsyncHTTPClienttohttp_client.py, mirroring the sync interface withasync def request(...).Also accepting the same constructor arguments as
_SyncHTTPClient.Using async with
httpx.AsyncClient(...)as client lifecycle management. And i'll ensure the acceptance criteria are met properly.grantfox-oss commentedon Aug 21, 2026
🦊 GrantFox — @DioChuks has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #8)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Aug 29, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!
@DioChuks's PR #58 was approved and merged by @codebestia.
🏆 @DioChuks: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (392 total points). Track your full progress on GrantFox.
👏 Great work, @DioChuks! Keep contributing to ShadeProtocol.