`fileUri` isn't supported by this model. — Veo on the Gemini API rejects this request field

Published 2026-09-23

Do not retry as-is

The exact error

`fileUri` isn't supported by this model.

What it means

Veo on the Gemini API does not recognise a field in your request. The name in backticks is the field it rejected. Every report of it cited here comes from the Gemini API channel (generativelanguage.googleapis.com with an API key), not from Vertex AI.

The clearest record is Google AI Developers Forum thread 107935. A developer called veo-3.1-generate-preview:predictLongRunning over REST with an x-goog-api-key header to extend a video, and tried seven payload shapes. Their results:

"video": {"fileUri": "files/..."} got this message. They described that shape as “Vertex AI style”.
"video": {"gcsUri": "gs://..."} got `gcsUri` isn't supported by this model.
"video": {"fileData": {"fileUri": ...}} got `fileData` isn't supported by this model.
A plain string, either the file name or the full file URL, and {"file": ...} got a different message: No struct value found for field expecting a video.

The same family appears with other field names. In forum thread 128760, a Veo 3.1 REST call that put referenceImages under parameters got a “referenceImages isn’t supported by this model” error. In js-genai issue #1059, passing raw video bytes for extension produced a 400 INVALID_ARGUMENT that said encoding isn’t supported by this model, followed by “Please remove it or refer to the Gemini API documentation for supported usage.” The raw log in that issue shows the backticks are part of the message.

Merged variant: No struct value found for field expecting a video.

This is the same problem from the other side. The video field expects an object, and a bare string or an unknown key does not fill it. Thread 107935 shows it for three different wrong shapes.

How to confirm it’s this

The message names a field in backticks and says it isn’t supported by “this model”.
Your request goes to generativelanguage.googleapis.com, not a Vertex AI endpoint.
Compare your JSON with Google’s Veo REST examples on the Gemini API page. They put every input inside instances[0]: image, lastFrame, referenceImages and video. Media is sent as {"inlineData": {"mimeType": ..., "data": ...}}. None of the examples use fileUri, gcsUri or fileData.
Check the model. Google’s parameter table lists referenceImages for Veo 3.1 and Veo 3.1 Fast, and marks it n/a for Veo 3.1 Lite and for Veo 3 and Veo 3 Fast.

Fix

Use the shapes in Google’s Gemini API examples. Put image, lastFrame, referenceImages and video in the instance, and send media as inlineData. In thread 128760, referenceImages sat under parameters, while Google’s table and examples place it among the instance fields. That thread got no answer, so this is a likely cause, not a confirmed one.
For extension, use the previous generation. Google’s docs say the Gemini API only extends Veo-generated videos, and the SDK examples pass operation.response.generated_videos[0].video. A js-genai contributor said the same in issue #1059: pass the previously generated video, because raw bytes are not supported for extension on the Gemini API.
If your code was written for Vertex AI, do not reuse its payloads unchanged. The developer in thread 107935 called the fileUri shape “Vertex AI style”, and it failed on the Gemini API. The js-genai contributor pointed to the Vertex AI backend for extending arbitrary videos. That route needs a Google Cloud project and its own auth, so follow the Vertex docs there.

One reply in thread 107935 claimed extension only worked with veo-2.0-generate-preview and a gcsUri object. That conflicts with the original poster’s gcsUri result and with Google’s current docs, which show Veo 3.1 extension on the Gemini API. Treat it as an unverified user report.

Retry or not

No. The API rejects the request’s structure, so the same body fails every time. Change the payload, then send a new request. An agent should surface this as a code bug, not retry it. If you see the message in production after a period without it, compare against Google’s current examples, because several of these reports predate the current docs.

When it’s not this

Input video must be a video that was generated by VEO that has been processed. The request shape was accepted, but the video itself was not an eligible Veo generation.
last_frame parameter is not supported in Gemini API. That is an SDK-side error raised before anything is sent.
Unable to process input image. That message points at the image data, not at a field name.

Error text last verified against the sources below on 2026-09-23.