generation API null parameters: Choose omission deliberately at each layer

The generation API null parameters contract is easiest to understand as several sequential decisions. The HTTP body is parsed, selected aliases are combined, undefined properties are deleted, and a provider schema validates the result. Null does not have one universal meaning across these stages.

Inspect a direct field

Seed is assigned directly from body.seed. If it is missing, the property becomes undefined and the route deletes it. The optional integer schema then sees an omitted seed. If seed is explicitly null, the route keeps it, and the integer schema rejects it. Zero is an integer and remains present.

Prompt follows the same direct assignment pattern, but its schema requires a nonempty string. An omitted prompt fails validation rather than acquiring a default. Explicit null also fails. An empty string fails the minimum length requirement, while a string consisting of spaces passes that length check unless your application applies a stricter policy.

These cases should be different rows in your client fixtures. Replacing all of them with a single empty value hides the reason a request was rejected.

Inspect an aliased field

Aspect ratio uses aspect_ratio ?? aspectRatio. A null snake case value causes the camel case candidate to be considered. If both are absent or resolve to undefined, the route removes the property and the provider’s default applies. If the camel case candidate is also null, the constructed property can remain null and fail the enum schema.

An empty string does not trigger this fallback. It reaches the enum validator and fails. An empty array for image_inputs similarly remains an array, rather than being treated as omitted. The schema accepts the optional array, and the adapter has no first image to map.

Define your own input policy

For a settings form, decide whether clearing a control means restoring the default or reporting a required value. Encode that decision before building the HTTP body. A clear button that removes the property is easier to reason about than a control that sends null while the user expects a provider default.

For patch-like application settings, null may have a legitimate local meaning such as removing a saved reference. Convert that local operation into the appropriate complete generation request. The generation endpoint is a submission endpoint, so do not assume database patch semantics.

Preserve the user’s intent separately from the final serialized body if an audit needs both. The parsed provider parameters are another useful boundary because defaults have already been applied there.

Acceptance without generation

Build a matrix for missing, null, empty string, zero, and a valid explicit value. For each field, document alias selection, the post-filter value, and the schema outcome. Review it against the chosen model rather than a generic parameter list.

Accept the client when clearing a setting yields the intended omission and seed zero survives serialization. Continue with alias precedence, empty prompts, and seed zero for concrete boundary cases.

Continue with models and parameters

• Flux API key: two paths, and what changes after you have one
• Flux API parameters: every accepted value and what it costs
• Flux aspect ratio options: what it accepts and what it rejects
• Browse all models and parameters guides