cinematic_studio_video_3_5: all media inputs rejected with "IP check not finished for input media" (3.0 and seedance accept identical uploads)

[udAIan]

Summary

Every generate create cinematic_studio_video_3_5 call with any media input fails immediately with:

Error: IP check not finished for input media

The error persists indefinitely (>1 hour, repeated retries), regardless of upload method, format, or media role. The identical upload IDs are accepted instantly by cinematic_studio_3_0 and seedance_2_0_mini, so this is specific to the 3.5 model's media gate, not the media itself.

Environment

• CLI: higgsfield 1.1.10 (d2f5198) built 2026-07-08
• Plan: Plus (private workspace), sufficient credits
• Date observed: 2026-07-10, ~02:20–04:00 UTC (continuously)

Repro

higgsfield upload create ./cafe.jpg   # returns upload id OK
higgsfield generate create cinematic_studio_video_3_5 \
  --prompt "..." --start-image <upload_id> \
  --duration 4 --resolution 1080p --prompt_language en --wait
# => Error: IP check not finished for input media (exit 3)

Ruled out

• Format: tried webp and jpeg re-encodes → same error
• Upload path: CLI upload create AND web-UI uploads (which pass the UI's synchronous validation) → same error via CLI
• Media role: --start-image and --image-references → same error
• Time: retries over 60+ minutes across 4 distinct upload ids → never clears
• The media: same upload ids generate fine on cinematic_studio_3_0 and seedance_2_0_mini, first try
• Content: ordinary cafe interior photo, no brands/celebrities

Likely cause (from job-history inspection)

UI-created 3.5 jobs (via generate list --json) attach media through reference_elements entries that carry an ip_detected field — i.e., IP-check state is tracked per element on the UI's internal path. Media attached via the public API's plain medias roles appears to never receive that IP-check state, so the 3.5 gate waits forever. 3.0 presumably doesn't consult this gate, which is why it works.

Expected

Either run the IP check on public-API media inputs for 3.5 (and have submission wait/poll briefly), or return a clear terminal error. A related nice-to-have: expose the UI's reference_elements and camera params (camera_model, camera_lens, camera_focal_length, camera_aperture) in the public schema — currently rejected as unknown params despite being visible in stored job params (related: #15).

[elephantpink-boop]

Confirming this on seedance_2_5 as well, with what we believe is the root cause.

Same symptom. Every image we pass to seedance_2_5 in mode: omni_reference via the hosted MCP is rejected with 400: IP check not finished for input media, and the state never resolves — we retried over more than an hour.

What we ruled out, in case it saves anyone time:

• 8 references at once, and each of 9 images individually (one call per image) — all rejected identically.
• media_upload (presigned PUT + media_confirm, all HTTP 200) — rejected.
• media_import_url re-importing from Higgsfield's own CloudFront URL — rejected.
• Passing reference_elements explicitly — the validator refuses it (mode 'omni_reference' requires at least one reference media item), and supplying medias re-arms the stuck gate.
• The identical media IDs are accepted instantly by seedance_2_0. The media is fine.

Sample request IDs, all the same error:

8161c913-819d-4982-9fec-542472d05eda
e78ee14e-e780-4249-846b-176e1bb181f9
391dcb1a-dda9-420b-be23-9e58c8168b92
40e7bdbe-9f8a-4e32-9fb5-eb5f077c15fd
1269a0b4-7dbc-4c2b-ade6-5422a487c805
4c477c6e-0aa8-4f92-aeec-771014eddd09

The root cause, and a workaround that works.

Driving the web UI directly shows what the API hides. In the asset picker, uploads sit under a banner reading "Protected content is not allowed", each tile labelled "Not eligible", with a per-asset "Check eligibility" button. Nothing equivalent is exposed over the API.

Clicking that button and letting the check finish flips the asset to eligible — and the very same media IDs are then accepted by seedance_2_5 over MCP on the first try. In our case 245 of 256 assets passed.

So the eligibility state is only ever written by the web path, exactly as suspected in the original report. Media uploaded through the public API/MCP never gets it, and the 2.5 gate blocks forever.

The workaround: upload through the web asset picker, run "Check eligibility", then use those uuids as medias[].value in the API. Tedious, but it unblocks production.

What would fix it properly:

1. An API call to trigger the eligibility check and read its state, so API-uploaded media is usable without a browser.
2. A real error instead of an indefinite block — return "not eligible" rather than "check not finished". The current message points at the wrong problem entirely and cost us most of a working day on a paid Ultra plan.

Happy to provide more request IDs if useful.