INVALID_PARAM: Invalid params — why a valid duration fails on one model

{
  "error": {
    "type": "invalid_param",
    "code": "INVALID_PARAM",
    "message": "Invalid params — durationSec: Invalid input",
    "param": "durationSec"
  }
}

The param field names the offending key and the message carries the validator’s own explanation. Nothing was submitted upstream and no credits were touched.

The constraint is per model, not global

This is the usual cause. A value that is valid on one model is rejected on another, because each model exposes its own schema:

Parameter	Seedance 2.0 Fast	Kling 2.0 Standard	Veo 3
duration_sec	any integer 3–15	5 or 10 only	8 only
resolution	720p or 1080p	1080p only	720p or 1080p
aspect_ratio	5 options	3 options	3 options

So duration_sec: 7 succeeds on Seedance and fails on Kling. duration_sec: 5 fails on Veo 3, whose duration is a fixed literal rather than a range.

For the image models, n is an integer from 1 to 4 on all three, so a value above 4 is the only thing that errors there.

Both naming styles are accepted

Request bodies read snake_case or camelCase — duration_sec and durationSec both work. The error message reports the internal camelCase name, so a complaint about durationSec refers to the duration_sec you sent.

This used to be a 500

Worth stating plainly, because it changes how to read older logs. Schema failures previously threw a plain error, which the top-level handler wrapped into:

{ "error": { "type": "internal_error", "code": "INTERNAL",
             "message": "internal server error" } }

A client mistake reported as a server fault, with the real reason discarded. If you have internal server error entries from generation calls in your logs, some share of them were this. It now returns 400 with the field name.

Related

An unrecognised model value is a different error — see UNKNOWN_MODEL. Malformed JSON never reaches validation at all and returns INVALID_JSON.