Cannot automatically set the API key from the configuration,

Error message

Cannot automatically set the API key from the configuration, it must be specified in the OpenAPI definition

What it means

In the generated Rust (hyper) client, each operation's auth is normally set from the spec's security requirements before the request is built. request.rs's fallback closure only runs when auth was never set — which happens for operations declared without a security requirement. In that state the generator refuses to guess: if Configuration has an api_key set but the operation declares no apiKey scheme, it panics with 'Cannot automatically set the API key from the configuration...' because it cannot know the key's name or where to insert it. This is a runtime panic in the calling process, not a generation-time error.

Source

Thrown at modules/openapi-generator/src/main/resources/rust/request.rs:149

        let query_string_str = query_string.finish();
        if !query_string_str.is_empty() {
            uri_str += "?";
            uri_str += &query_string_str;
        }
        let uri: hyper::Uri = match uri_str.parse() {
            Err(e) => return Box::pin(futures::future::err(Error::UriError(e))),
            Ok(u) => u,
        };

        let mut req_builder = hyper::Request::builder()
            .uri(uri)
            .method(self.method);

        // Detect the authorization type if it hasn't been set.
        let auth = self.auth.unwrap_or_else(||
            if conf.api_key.is_some() {
                panic!("Cannot automatically set the API key from the configuration, it must be specified in the OpenAPI definition")
            } else if conf.oauth_access_token.is_some() {
                Auth::Oauth
            } else if conf.basic_auth.is_some() {
                Auth::Basic
            } else {
                Auth::None
            }
        );
        match auth {
            Auth::ApiKey(apikey) => {
                if let Some(ref key) = conf.api_key {
                    let val = apikey.key(&key.prefix, &key.key);
                    if apikey.in_query {
                        query_string.append_pair(&apikey.param_name, &val);
                    }
                    if apikey.in_header {
                        req_builder = req_builder.header(&apikey.param_name, val);
                    }

View on GitHub (pinned to fcec517be3)

Solutions

Declare the security requirement on the operation (or globally) in the spec, e.g. security: [{ ApiKeyAuth: [] }], and regenerate — the generated call will then set Auth::ApiKey explicitly and never hit the fallback.
Otherwise remove api_key from the Configuration used for operations that have no security requirement (leave it None).
If the operation should be public but you need the key elsewhere, use a separate Configuration instance for the authenticated calls.

Example fix

# before (openapi.yaml) — operation has no security, yet Rust code sets conf.api_key
paths:
  /users:
    get:
      operationId: getUsers
      responses: { '200': { description: ok } }
# Rust: configuration.api_key = Some(ApiKey { prefix: None, key: "secret".into() });
# -> panics: Cannot automatically set the API key ...

# after (openapi.yaml)
paths:
  /users:
    get:
      operationId: getUsers
      security:
        - ApiKeyAuth: []
      responses: { '200': { description: ok } }
# regenerate; generated code passes Auth::ApiKey(..) explicitly

Defensive patterns

Strategy: validation

Validate before calling

// Rust: pre-flight check before calling an operation known to lack security
fn assert_auth_compatible(conf: &Configuration, op_has_security: bool) {
    if !op_has_security && conf.api_key.is_some() {
        panic!(
            "conf.api_key is set but this operation declares no security scheme; \n\
             remove api_key from Configuration or add `security` to the operation in the spec"
        );
    }
}

Type guard

fn has_security_requirement(spec: &OpenApi, operation_id: &str) -> bool {
    spec.paths.iter().any(|(_, pi)| {
        pi.iter().any(|(_, op)| {
            op.operation_id.as_deref() == Some(operation_id)
                && !op.security.as_ref().map(|s| s.is_empty()).unwrap_or(false)
        })
    }) || spec.security.as_ref().map(|s| !s.is_empty()).unwrap_or(false)
}

Prevention

This is a panic, not a Result — it cannot be caught idiomatically; prevent it by construction.
Give every protected operation an explicit security entry in the spec and keep Configuration.api_key unset for public-only clients.
Use one Configuration per auth profile instead of one shared catch-all Configuration.

When it happens

Trigger: The OpenAPI operation being called has no security entry (or only securitySchemes without a matching requirement), while the app builds Configuration { api_key: Some(ApiKey { .. }), .. }. First call to that operation's async fn hits the panic. Also occurs when the spec relies on a global security section that the operation-level empty security array [] explicitly clears.

Common situations: One Configuration shared across a client that mixes authenticated and public endpoints; specs where security is defined at the scheme level but never referenced by an operation/`security` block; passing api_key 'just in case' for a spec that actually uses oauth/basic.

Related errors

AI-assisted analysis of OpenAPITools/openapi-generator@fcec517be3 (2026-08-22). Data as JSON: /api/errors/5957e215114dbc27. Report an issue: GitHub.