2026-09-29

400 unknown_parameter on a Format run: read the suggestion

Sume rejects a top-level field it does not know with 400 unknown_parameter and names the likely one. Why webook_url and thread_id fail, and the fix.

4 min readSume

All posts

400 unknown_parameter on a Sume Format run means the body has a top-level field the API does not know. The error carries details.errors[].suggestion naming the likely intended field, so a typo such as webook_url comes back pointing at webhook_url. Rename or remove the field and resend. Nothing ran and nothing was charged.

This follows Create a run and Format API errors, read 2026-09-29.

What exactly does Sume reject?

Unknown top-level fields are 400 unknown_parameter, with a suggestion when the name is close. The run is refused instead of started with the field ignored, so a misspelled webhook_url cannot slip through to a run that never calls your webhook.

The check applies to top-level fields. input is different: it is the JSON object your service hands to the run, Sume publishes no field list for it, and you choose its shape.

Which mistakes trigger it?

The two the docs name are a typo in a real field and thread_id. A continuation is a new run that names previous_run_id, never a thread id: sending a thread id is 400 unknown_parameter.

From Create a run and Runs and results, read 2026-09-29.
You sent	Answer	Fix
`webook_url` (typo)	`400 unknown_parameter`, suggestion `webhook_url`	Use the suggested name
`thread_id` to continue a run	`400 unknown_parameter`	Send `previous_run_id` instead
`{}` or `{"input": {}}`	`400 invalid_request`	Name at least one of `instruction`, `input`, `previous_run_id`, `attachments`
Both `output_schema` and `response_format`	`400 invalid_request`	Send one

How do I read the suggestion?

Branch on error.code first, then read details.errors[]. Each entry can carry a suggestion. A short check makes the fix obvious in logs:

curl -sS -X POST "https://api.sume.com/v1/formats/acme/product-video/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-8823-lc-v1" \
  -d '{"instruction":"Make the launch video.","webook_url":"https://example.com/hooks/sume"}' \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['error']['details']['errors'])"

Can I reuse the Idempotency-Key after the fix?

Yes. A failed create releases its Idempotency-Key, and a 4xx at create costs nothing. Fix the body and resend with the same key. Derive the key from the thing being made, such as your order id.

Does the same rule cover the bulk endpoint?

The errors page lists create errors for both POST /v1/formats/{handle}/{slug}/runs and POST /v1/formats/{handle}/{slug}/bulk-runs in one table, so the codes above apply to both. On a bulk body, a bad concurrency or items is 400 invalid_request. Fix the body the same way: read the code, read details, correct one thing at a time, and resend.

Is there a field list to check against?

Yes, for the top level. The request body table on the create page lists instruction, input, attachments, output_schema, response_format, primary_output_key, generation_spend_cap_usd, communication.webhook_url, communication.mode, previous_run_id, on_active_run, model and idempotency_key. The docs also say that top-level webhook_url, callback_url and mode are normalized into communication, so those three are accepted at the top level.