1.15.0
(feat): Add support for OAuth 2.0 client-credentials authentication. Clients configured with an
oauth/client-credentials scheme now accept client_id/client_secret (with environment
variable fallback) and generate an OAuth token provider that fetches, caches, and refreshes the
access token from the configured token endpoint.
(fix): Send client_id/client_secret (and other required token-request properties) when the OAuth
token endpoint’s request body is a named/referenced type. Previously only inlined request bodies
were handled, so a referenced body produced an empty token request and authentication failed.
(fix): When both an inferred-auth scheme and an OAuth scheme are present (e.g. auth: any), instantiate
a single auth provider instead of emitting two @auth_provider assignments where the OAuth block
silently clobbered the inferred-auth block. The provider that appears first in the declared auth
order is selected.
(fix): Fix a backward-compatibility regression under any-composed multi-scheme auth: the OAuth (and
inferred-auth) provider is now conditional on its credentials being present. Previously the client
unconditionally instantiated the provider and merged its auth_headers in initialize, firing a
synchronous token request at construction — so an existing api-key-only consumer calling
Client.new(api_key: ...) without OAuth credentials made a live network call and raised. The
provider is now only created (and merged) when its credentials are supplied; otherwise the client
falls back to the other any scheme (api key/basic/bearer) and never touches the token endpoint.
Auth parameters are also relaxed to optional under any-with-multiple-schemes. A single mandatory
OAuth scheme keeps its existing (eager) behavior. The credentials check treats a set-but-empty
string (e.g. OAUTH_CLIENT_ID="") the same as absent, so an existing api-key-only consumer with
empty OAuth environment variables still falls back to the api-key path instead of firing a token
fetch at construction.
1.14.1
(fix): Normalize the architecture label in the structured User-Agent (emitted when
includePlatformHeaders is enabled) so the 64-bit x86 aliases (x64,
amd64, x86_64) all report as the canonical x86_64, keeping the value
consistent across generators.
1.14.0
(feat): Add opt-in support for a structured User-Agent header on generated clients.
When enabled it reports the SDK name/version, operating system, CPU
architecture, and Ruby runtime version, e.g.
my-sdk/0.0.1 (linux; x86_64) Ruby/3.2.0. The operating system, architecture,
and version are resolved at runtime; unknown components are omitted rather
than emitted as placeholders. This is gated behind a new
includePlatformHeaders config option and is disabled by default, so existing
generated output is unchanged. When enabled it is still subject to the
omitFernHeaders option.