Rust SDK generator from OpenAPI

Scalar can generate a Rust crate from your OpenAPI document, with async pagination, WebSocket support for AsyncAPI channels, and a release workflow that publishes to crates.io using trusted publishing. The Rust target is experimental. It generates working code, but it is further from GA than Java, Kotlin, Ruby, and C#, and there is no public Rust sample yet. This page describes what is documented and says plainly where it is describing what the generator targets rather than showing output.

Where the Rust target is ahead

Rust is experimental, but in a few places it does more than any other Scalar target, and those are worth knowing up front:

• It follows next-page URLs. If your API returns a complete URL for the next page (a cursorUrl scheme read from a bodyLink response field), the Rust target re-issues the request against that URL. It is currently the only target that does. Every other target handles a cursor token, not a URL.
• It ships a WebSocket runtime. When you generate from an AsyncAPI document (AsyncAPI support is itself experimental), WebSocket connect methods are generated only for TypeScript, Python, Rust, and the CLI. Other targets get the event types but nothing that opens a connection.

If your API streams over WebSockets or pages by URL, that makes Rust a more complete target for you than its experimental label might suggest.

What the generator targets for Rust

Async pagination with a pager. The pagination guide documents that a paginated Rust method gives you a pager you advance with .await:

// `request` stands for a paginated list call built from your client.
let mut pager = request.paginate();
let next = pager.next().await;

For page-level control, the guide documents Pager::next_page. Treat the exact types (for example, whether items arrive wrapped in a Result) as something to confirm in your preview.

The same API shape as every other target. Resources and methods come from one configuration, with normalised verbs (list, retrieve, create) cased for Rust, so a support answer written for your TypeScript users maps onto the crate.

The generator's shared feature set. The SDK Generator's feature list covers retries on temporary failures (twice by default: network errors, 408, 409, 429, 5xx) with Retry-After support, a 60-second default timeout, typed errors carrying status, headers, and body, and credentials from your security schemes with environment variable defaults. On an experimental target, confirm how each surfaces in the crate.

A limitation to know about. Rust does not read itemCursor or cursorPath, so a scheme relying on either stops after the first page. Prefer a top-level cursor field where your API offers one.

Configure the target

{
  "targets": {
    "rust": {
      "packageName": "acme",
      "destinations": {
        "production": { "repo": "acme/acme-rust" }
      },
      "publish": {
        "cargo": {
          "authMethod": "oidc",
          "homepage": "https://acme.com",
          "description": "Acme API Rust SDK"
        }
      }
    }
  }
}

packageName is the crate name on crates.io. crates.io names are first come, first served and global, so check the name is free before your first release. See the Rust configuration reference.

Publishing to crates.io

crates.io supports trusted publishing, and it is the recommended path. The generated release workflow uses rust-lang/crates-io-auth-action to exchange the GitHub workflow's identity token for a short-lived crates.io token, so nothing long-lived is stored.

1. On crates.io, open the crate's Settings → Trusted Publishing and add a GitHub publisher for your repository with the workflow file release-please.yml.
2. Keep "publish": { "cargo": true } (OIDC is the default).
3. Merge the release pull request Scalar keeps open in your repository.

If you cannot use OIDC, create a token with the publish-update scope, store it as CARGO_REGISTRY_TOKEN, and set "authMethod": "access-token". Before running cargo publish, the workflow queries crates.io for the version and skips it if it already exists, so re-merges are safe. Details are in crates.io publishing.

Scalar compared with OpenAPI Generator for Rust

OpenAPI Generator's rust generator is stable and free. It supports four HTTP libraries: reqwest (the default), reqwest-trait, hyper (Hyper 1.x), and hyper0x. With reqwest, supportAsync defaults to true, and supportMiddleware adds reqwest-middleware support, which is a clean way to bolt on retries or tracing yourself. Its feature table marks oneOf as supported and allOf and anyOf as unsupported.

If you need control over the HTTP stack, a trait-based client for mocking, or a stable generator today, OpenAPI Generator is a good fit and we would say so.

For the broader decision, see OpenAPI Generator alternatives.

Documenting a Rust API, too

If your API is written in Rust, Scalar's API reference already has integrations for Axum, Actix Web, and other Rust frameworks. The OpenAPI document those frameworks produce, for example through utoipa or aide, is the same input the SDK generator uses.

Frequently asked questions

Related

• Learn: Generate an SDK from OpenAPI · OpenAPI Generator alternatives
• Docs: Rust configuration · Publishing to crates.io
• Product: SDK Generator — preview a Rust crate from your own OpenAPI document

OpenAPI Generator details are taken from openapi-generator.tech and the OpenAPITools/openapi-generator repository as of September 2026 (release 7.25.0). If something here is out of date, please open an issue and we will fix it.