4.13.2

(fix): Fix the OAuth OAuthTokenSupplier generator to derive each get-token request property’s Java type from its IR TypeReference (via PoetTypeNameMapper) instead of hardcoding String. Previously a non-string token-request property (e.g. permissions: Optional<List<String>>) generated a String field and a .permissions(String) builder call that did not match the request builder’s typed setter, breaking compilation of the entire SDK. The generated custom property fields, constructor parameters, client-builder setters, and request builder calls now use the property’s real type.

To preserve backward compatibility, any get-token custom property whose real type is Optional<X> also gets an unwrapped setter overload accepting X directly (mirroring the request model’s convenience setters), so existing callers such as .scope("value") continue to compile unchanged.

4.13.1

(fix): Make the generated User-Agent comply with the RFC 7230 token grammar. The Maven coordinate in the product token now uses a dot instead of a colon, since a colon is not a valid token character (e.g. com.fern:imdb/0.0.1 becomes com.fern.imdb/0.0.1); this applies to both the plain header value and the structured value emitted when includePlatformHeaders is enabled. For the structured value, the architecture label is also normalized so the 64-bit x86 aliases (x64, amd64, x86_64) all report as the canonical x86_64.

4.13.0

(feat): Add opt-in support for a structured User-Agent header on generated SDK clients, of the form {sdkName}/{sdkVersion} ({os}; {arch}) {runtime}/{runtimeVersion} (e.g. com.fern:sdk/0.0.1 (linux; amd64) Java/17.0.13). The os (System.getProperty("os.name"), lowercased), arch (System.getProperty("os.arch")), and runtime version (System.getProperty("java.version")) are resolved at runtime; any segment that cannot be determined is omitted rather than emitted as null. This is gated behind a new includePlatformHeaders config option and is disabled by default, so existing generated output is unchanged. When enabled, the header is still subject to omit-fern-headers.

4.12.1

(fix): Decompress gzip and deflate encoded response bodies via a new ResponseDecompressionInterceptor added to the generated OkHttpClient. OkHttp only performs transparent gzip decompression when it adds the Accept-Encoding header itself, so responses to requests with a spec-defined Accept-Encoding: gzip header were previously returned as raw gzip bytes.