What is the problem this feature would solve?
The generated HttpApiClient always requires the Type side of endpoint schemas and runs Schema.encode internally. This forces callers to construct types (e.g., Option values) even when the Encoded side is more ergonomic (e.g., using undefined to omit optional fields).
For schemas using patterns like OptionFromNullishOr, the encoded representation (undefined / null) is often the natural input shape at call sites, but the client API demands the decoded Option wrapper.
What is the feature you are proposing to solve the problem?
Add an opt-in way to bypass request payload encoding and send the raw Encoded payload directly.
Per-client/Per-request, accept an option like { encodeRequests: false } or { allowEncodedInput: true }
When enabled, the client skips Schema.encode for the payload and uses the provided value directly.
What alternatives have you considered?
No response
What is the problem this feature would solve?
The generated
HttpApiClientalways requires the Type side of endpoint schemas and runsSchema.encodeinternally. This forces callers to construct types (e.g.,Optionvalues) even when the Encoded side is more ergonomic (e.g., usingundefinedto omit optional fields).For schemas using patterns like
OptionFromNullishOr, the encoded representation (undefined/null) is often the natural input shape at call sites, but the client API demands the decodedOptionwrapper.What is the feature you are proposing to solve the problem?
Add an opt-in way to bypass request payload encoding and send the raw Encoded payload directly.
Per-client/Per-request, accept an option like
{ encodeRequests: false }or{ allowEncodedInput: true }When enabled, the client skips
Schema.encodefor the payload and uses the provided value directly.What alternatives have you considered?
No response