Changelog
Keep track of changes and improvements to Stainless.
Add code samples to Mintlify docs with a copy-paste
You can now add SDK code examples to your Mintlify docs with a one-line setup.
Simply paste the OpenAPI URL into your docs.json file. See docs for more information.
MCP server supports client capabilities
Our Model Context Protocol (MCP) server now adapts to different client capabilities when serving tools generated by Stainless.
MCP clients like Claude Desktop, Cursor, or OpenAI Agents each handle the JSON schemas provided by MCP servers differently. For example, Cursor has a strict 60-character tool name length, and Claude Code does not support unions of objects at the top level of a tool.
To mitigate this, users can provide a --client argument to our MCP server to specify which client they are working with, and our server will automatically transform the generated JSON Schemas to serve clients a format that is compatible.
For example: npx my-api-mcp --client=claude-code
You can read more about the transformations in our recent blog post.
Ruby general availability
The Ruby SDK generator is now generally available, with modern type system support and a minimal-dependency design that feels right at home in the Ruby ecosystem.
- Sorbet: Each SDK includes comprehensive RBI annotations, including enums and aliases, without a dependency on sorbet-runtime.
- RBS: Each SDK also includes Ruby 3’s RBS type annotations, compatible with the steep typechecker.
- YARD: Full YARD docs support for methods and types, with navigable links between related objects, published to Gemdocs automatically.
- Tooling support: Great auto-completion for ecosystem tool chains, including generics for pagination & streaming for all supported language services.
- File uploads & downloads: Full lazy upload and download support with conveniences like Pathname support.
- Type conversions: Automatic conversions to Time, Integer and so on as appropriate.
- Pattern matching: All data containers support Ruby 3 pattern matching.
- Minimal dependencies: The SDKs use stdlib net/http for requests, relying only on connection_pool.
- Introspection: Pretty printing is supported for all internal types, for both classes and instances.
- Streaming: Support for SSE & JSON-L streams as ruby Enumerators, allowing for convenient .map, .filter, and so on, with automatic closing during GC.
- Advanced use cases: Raw and undocumented request support.
We plan to add support for middleware soon, along with other conveniences; if there’s more you’d like to see, please share: hello@stainless.com.
TypeScript SDK generator V2
We have shipped a “v2” of our Node / TypeScript SDK generator, focused around dropping support for EOL versions of Node and removing node-fetch in favor of the now-stable built-in fetch.
Upgrading to the new SDK requires a major version bump for any 1.0 or later SDK, though typically most developers will not be required to change any code.
The new SDKs are lighter, more consistent, and have zero dependencies out of the box. We also took the opportunity to clean up a variety of details along the way.
- Native fetch support: node-fetch has been removed in favor of the native web Fetch API, as we have dropped support for Node 16 which did not include it as a stable builtin.
- Zero dependencies: All runtime dependencies have been removed!
- Clearer path parameters: Methods with multiple path parameters now use named arguments instead of positional ones.
- Automatic path parameter encoding: Path parameters are now automatically URI-encoded. If you were manually calling encodeURIComponent(), you should remove it.
- fetchOptions replaces httpAgent: The httpAgent option is removed. The new fetchOptions property can be used for things like proxy configuration, taking advantage of platform APIs.
- Consistent method naming: All delete operations now consistently use .delete() instead of .del().
- Simplified pagination: Pagination methods are simpler and more consistent. nextPageRequestOptions() replaces nextPageParams() and nextPageInfo().
- Lighter type system: Pagination classes are now simple type aliases instead of runtime classes.
- Streamlined file uploads: The deprecated and platform-specific fileFromPath helper has been removed. Instead, users can use fs.createReadStream or Bun.file directly.
Terraform provider general availability
Our Terraform Provider generator is now generally available.
If any of your users would like to configure resources in your API with Infrastructure as Code (IaC) using Terraform, they can now do so.
Our Terraform providers generate Hashicorp docs, handle complex datatypes, and support custom acceptance tests and state migrations to ensure robust deployments.
Simply select Terraform from the languages list in the SDK Studio to get started:
- The Terraform Provider uses the Go SDK, so it will be enabled as well, if it isn’t already.
- Enable some resources and address any diagnostics.
- Try the provider locally.
Ruby Sorbet support
Sorbet type definitions are stable with improved autocomplete for models.
Stainless Ruby SDKs are among the first to support type annotations without relying on sorbet-runtime, giving you static analysis without the extra overhead.
It’s also the first to offer Sorbet, RBS, and YARD docs with full generics.
MCP servers
Stainless can now generate an MCP server for your API. The feature is currently experimental and is free to all users.
Get the full details in the launch blog.
Editor improvements in Studio
The SDK Studio features an improved editor. This provides a more consistent coding experience and comes with improved autocomplete and cmd+click navigation.
Publish documented OAS toggle

Users with code snippets enabled in their Stainless config can toggle a feature in the Studio UI to make their documented OpenAPI spec downloadable via a public URL.
Templated base URLs
For APIs where the base URL includes dynamic segments like a region subdomain (https://{region}.acme.com), you can map client options to them with the server_variable property in your Stainless config.
This allows your SDK users to set region directly without constructing custom baseURLs.
Go default parameters
Users can now set global default values for path and query parameters via client options in the Go SDK.
Ruby public beta
You can now generate a Ruby SDK for your API using Stainless. Once your project is configured, follow this guide to get started.
See it in action here: Modern Treasury Ruby SDK.
For any feedback or feature requests, ping hao@.
Javadocs and KDocs
Java and Kotlin SDKs come with hosted API docs—Javadocs and KDocs are published to javadoc.io and linked from the README.
Autoguesser V2
The autoguesser is built-in tooling that helps turn your OpenAPI spec into the Stainless Config.
“V2” of our autoguesser comes with:
- Improved model guessing
- Smarter default config for features like pagination and OAuth
- Fewer diagnostics out of the box, providing a smoother setup experience
- Better handling of large OpenAPI specs where not all endpoints can be guessed at once
Java/Kotlin general availability
The Java and Kotlin SDK generators are now generally available, with improved support for complex OpenAPI specs and several new features.
- Convenient builders for complex objects: The SDKs now include helper methods to make building complex objects easier, such as .addCard(Card) alongside .cards(List<Card>) or .addUserMessage(String) for a discriminated union like {role: 'user', message: string}.
- Automatic cleanup for unreachable objects: The HttpClient and other resources are now closed automatically when no longer in use, even if the user forgets to call .close() (available in Java 9+).
- File uploads: Multipart form data is fully supported, even with nested file fields. Builders like FileCreateParams.builder().file(...) accept byte[], InputStream, or Path, and stream data directly to the API, without buffering in-memory whenever possible.
- Binary responses: Methods like client.files().retrieve(...) return an HttpResponse with a .body() stream. This is ideal for handling binary data without loading it all into memory.
- Raw response access: Easily access headers and more for any method call; for example, client.cards().withRawResponse().create(...) returns an HttpResponseFor<Card> with .headers(), .parse(), etc.
- SSE and JSONL streaming: Endpoints with streaming responses are now supported (e.g., client.chat().completions().createStreaming()).
- Jackson compatibility: The SDKs work with Jackson versions as old as 2.13.4, minimizing the chance of version conflicts in downstream applications.
We have a slew of additional improvements to our Java SDKs planned; please reach out to hello@stainless.com with anything you’d be most excited to see.
“Integrations” section in docs
Stainless docs now have an “Integrations” section with guides on integrating with other platforms. Check out the first integration guide with bump.sh.
Java/Kotlin OpenAPI decoration support
Stainless now outputs Java/Kotlin code snippets, which will be read by API reference documentation providers and displayed in your documentation.
Here is an example (binary response handling) of the code snippets:
→ stainless.com
The SDK Studio is now served from app.stainless.com, with the homepage updated to stainless.com (formerly stainlessapi.com).
Terraform SDK preview in the SDK Studio

The SDK Studio now shows Terraform schemas and snippets in the SDK preview pane.
Semantic custom code conflict resolution
Stainless automatically resolves more repetitive, low-risk merge conflicts with a syntax-aware merge algorithm.
Define OpenAPI spec request examples
When generating code snippets for documentation providers, Stainless will prioritize the first example in your OpenAPI spec’s request examples.
Terraform public beta
Generate a Terraform Provider for your API using Stainless to allow your customers to automatically provision resources in your API. Follow this guide to get started. To see an example in action, try the Cloudflare v5 Terraform Provider.
For any feedback or feature requests, ping dackerman@.
Diagnostics redesign

You can now ignore specific diagnostics in the SDK Studio to better prioritize build-critical ones.
Config diffs in the SDK Studio

See changes you’re making to the Stainless Config and the OpenAPI spec before you save them.
Disabling retries in the Stainless Config
Setting max_retries
to 0 is now supported across our SDKs. Use this setting if retries are not compatible with your API.
x-stainless-deprecation-message

When deprecating a schema, SDKs will include a message. In your OpenAPI spec, add x-stainless-deprecation-message: <your message> alongside deprecated: true to use this feature.
JSONL support
SDKs now support endpoints that return JSONL responses. Mark your endpoint’s content type as application/jsonl or application/x-jsonl to use this feature.
Redesigned preview pane in the SDK Studio

The SDK Studio now features a redesigned preview pane with an improved look and feel. Use the preview pane to review complete language-specific content including method signatures, parameters, types, and more.
Project dashboard

The project dashboard page displays the status of each SDK, release configuration, and build history.
Java/Kotlin Debug logging
The Java and Kotlin SDKs support logging requests when setting a <OrgName>_LOG environment variable to info or debug depending on the desired verbosity.
This is also available in Python and TypeScript.
Removing Guava dependency
The Java and Kotlin SDKs now use custom, SDK-specific code instead of Guava, reducing generated JAR size by 10% (3 MB).
Java/Kotlin automatic resource closing
The Java and Kotlin SDKs automatically prevent accidental memory leaks. If a user forgets to close an HTTP response or client, then it will be automatically closed when it becomes phantom reachable.
X-Stainless-Retry-Count header
SDKs now include an X-Stainless-Retry-Count header in every request to indicate the current retry attempt. This provides better visibility into why requests are being sent to your API.
JSR support
Stainless now seamlessly integrates with JSR, a multi-platform package manager for TypeScript developed by the Deno team.