FLUX 3 Image API 422 unknown field vs Sume 400

On BFL's FLUX 3 Image endpoint a request with an unknown field returns 422, and so do a blank prompt, an invalid parameter value and a reference image smaller than 256 x 256 pixels. Sume splits it differently: a parameter the selected model does not list is rejected with 400 unsupported_parameter. If one client calls both, branch on the error code, not on 422.

BFL facts are from its FLUX 3 Image reference; Sume facts from the Image API and errors and credits, read 2026-10-01.

What does FLUX 3 Image return for a bad request?

The request schema sets additionalProperties: false, so any field it does not define is a validation error. The spec also says an entities field returns 422: boxes go into the end of prompt as a JSON list, not a separate parameter. A reference above 16 megapixels is a different case and returns 400.

What does Sume return?

Parameters on Sume carry typed descriptors in the catalog, and the docs say a request that sets a parameter the selected model does not list is rejected with 400 unsupported_parameter rather than silently dropped. A few fields are in the schema but advertised by no model in v1 (output_compression, seed and explicit pixel size), and they get the same error. The general table in the errors page lists 400 as invalid_request or bad_request for other malformed bodies.

How should my client handle both?

Treat 4xx as "do not retry unchanged" and read the body for the cause. For Sume, read the error code and, for unsupported_parameter, remove the field or choose a model whose supported_parameters lists it. For BFL, read the detail array (each item has loc, msg and type) to find the offending field.

Also keep field names per provider: a FLUX 3 request that works on BFL carries fields such as images and grounding that a Sume image request does not list, and Sume's catalog entries for FLUX are FLUX.2 Pro and Flex, not FLUX 3 Image. See what Sume serves for FLUX 3.

Is a silent drop ever possible on Sume?

Not for listed-or-not checks: the docs describe rejection instead of a silent drop. Where the docs note a value is accepted but inert, as for multi-provider routing fields, that is called out in the Sume specifics table, so read it before relying on a field.