Generative Language API has not been used in project 542708778979 — Veo video download 403 (Gemini API)

Published 2026-09-23

HTTP 403 PERMISSION_DENIED Do not retry as-is

The exact error

Generative Language API has not been used in project 542708778979 before or it is disabled.

What it means

Your video was generated. What failed is the download. When a Veo operation on the Gemini API finishes, it returns a file URI on generativelanguage.googleapis.com ending in :download?alt=media. If that URL is requested without your credentials, the API has no way to tie the request to your project, and the 403 names project 542708778979 instead.

That project number is not yours, and enabling the API won’t help. In Google AI Developers Forum thread 106512, the poster had the Generative Language API enabled in their own project, with billing and IAM set up. They pointed out that the number in the error was a project they did not own. In thread 96867, the original poster said they did not recognize the project, and another user reported the same number for every Veo model they tried. The message tells you to enable the API in that project and retry, but you cannot change a project you do not own.

A forum member with a Google badge explained in thread 96867 that getting this error is normal when you paste the URL into a browser without a key. They added that it should not come back from the SDK’s files.download.

How to confirm it’s this

The 403 comes from the GET on the files/...:download URL, not from the generate call or the operation poll. Both of those succeeded.
The project number in the message is 542708778979, not your project’s number.
Your download request has no x-goog-api-key header or other credentials. Code that hands the raw URI to a generic HTTP fetch, a browser or a frontend <video> tag hits exactly this.
In python-genai issue #1946, the full error body also carried an ErrorInfo with reason SERVICE_DISABLED.

Fix

Download the way Google’s Veo page shows it. The SDK examples call client.files.download(file=generated_video.video, ...) in Python and ai.files.download({ file, downloadPath }) in JavaScript. The REST example fetches the URI with curl -L, sends your key in the x-goog-api-key header, and follows redirects.
Update the SDK if its download misbehaves in your runtime. In thread 96867 the poster was on Supabase Edge Functions (Deno), and files.download produced nothing. Months later, the Google-badged responder linked a fix to the downloader in the JavaScript SDK and asked whether it solved the problem.
Community workaround: append the key to the URL. The accepted answer in thread 96867, which also resolved thread 106512, was to fetch the URI with &key= and your API key added. This is a community solution, not the documented method. Sending the key in the header, as Google’s REST example does, keeps it out of URLs.
Never hand a keyed URL to the browser. The poster in thread 106512 used the keyed URL “for frontend download”. Anyone who sees that URL in page source, logs or analytics has your API key. A later poster in thread 96867 made the same point and asked for signed URLs, and the thread gives no answer. The safe pattern is to download on the server with the key in a header, store the file in your own storage and serve your own URL.
Download promptly. Google’s Veo page says generated videos are kept on the server for 2 days and then removed.

Retry or not

No, not unchanged. Requesting the same URL without credentials returns the same 403 every time. The message’s own advice to wait a few minutes and retry is about enabling an API in your project, and this project is not yours. What you should retry is the download step alone, with credentials. Do not regenerate the video, because the existing one is still there until the 2-day retention window ends. An agent should keep “generate”, “poll” and “download” as separate steps with separate retry rules, so a download 403 never triggers a new generation.

When it’s not this

Your own project number in the message. In that case the API really is disabled or unused in your project. Enabling it and waiting, as the message says, is the right fix.
A different network setup. In python-genai issue #1946, files.download failed with 302 UNKNOWN in the reporter’s environment, and opening the URI directly showed this 403. The same code worked on another server. The cause was the reporter’s local network configuration, not the API.
Batch results. One user in thread 96867 reported the same message when downloading Batch API output with curl and the key header. That case was not resolved in the thread.
A 401 about API keys on the poll step is a different authentication problem.

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