Problem
WorkOsBuilder::build() always creates its own reqwest::Client internally:
let client = reqwest::Client::builder()
.user_agent(concat!("workos-rust/", env!("CARGO_PKG_VERSION")))
.build()
.unwrap();
There's no way to pass in an existing reqwest::Client. This means applications that already have a configured client (with custom timeouts, connection pools, TLS settings, etc.) end up with two independent connection pools to api.workos.com.
Proposed Solution
Add a client method to WorkOsBuilder:
impl<'a> WorkOsBuilder<'a> {
pub fn client(mut self, client: reqwest::Client) -> Self {
self.client = Some(client);
self
}
pub fn build(self) -> WorkOs {
let client = self.client.unwrap_or_else(|| {
reqwest::Client::builder()
.user_agent(concat!("workos-rust/", env!("CARGO_PKG_VERSION")))
.build()
.unwrap()
});
// ...
}
}
This is backwards-compatible — existing callers that don't set a client get the same default behavior.
Use Case
We wrap the WorkOS SDK in a client that also makes direct HTTP calls for operations not yet in the SDK (e.g., resend_invitation). Being able to share a single reqwest::Client would eliminate the duplicate connection pool.
Problem
WorkOsBuilder::build()always creates its ownreqwest::Clientinternally:There's no way to pass in an existing reqwest::Client. This means applications that already have a configured client (with custom timeouts, connection pools, TLS settings, etc.) end up with two independent connection pools to api.workos.com.
Proposed Solution
Add a client method to WorkOsBuilder:
This is backwards-compatible — existing callers that don't set a client get the same default behavior.
Use Case
We wrap the WorkOS SDK in a client that also makes direct HTTP calls for operations not yet in the SDK (e.g., resend_invitation). Being able to share a single reqwest::Client would eliminate the duplicate connection pool.