Veo 3.1 personGeneration: allow_adult vs allow_all by mode

In Veo 3.1, the personGeneration parameter controls whether people can appear. Google's page lists "allow_all" for text-to-video and "allow_adult" for image-based modes, and says users in the EU, UK, Switzerland and MENA are limited to "allow_adult". Sume has no personGeneration field, and Veo is not in its video catalog.

The Veo values are from Google's Veo page; Sume's request rules are from Video generation, both read 2026-09-29.

Which value goes with which Veo mode?

Why would a request fail on this?

The page ties the allowed value to the mode and to the user's region, so a value that is valid for text-to-video is not valid for an image-to-video call. If you see an error naming personGeneration, first check that the value matches the mode you are calling, then check the region rule above. The page does not describe an error message, so read the response body rather than assuming.

Is there an equivalent on Sume?

No. POST /v1/videos has no people-setting field. Its request fields are model, prompt, duration, resolution, aspect_ratio, size, frame_images, input_references, generate_audio, seed, callback_url and provider.

The provider object is for passthrough options, and the docs say the allowed list is empty for every model in v1, so entries under provider.options are rejected rather than silently dropped. A personGeneration key copied from a Google request would therefore fail on Sume, not be ignored.

What should I check before porting a Veo call?

• Remove Google-only parameters such as personGeneration; keep prompt, duration and aspect_ratio.
• Read supported_durations and supported_aspect_ratios for the target model in GET /v1/videos/models; Veo's 4, 6 or 8 seconds will not match every catalog model.
• Send a bare catalog id such as seedance-2.5, not a provider-prefixed one.
• Reuse an Idempotency-Key on retries so a repeated submit does not create a second job.