Calling Veo without setting up Google Cloud

Updated 2026-10-02

Most developers who search for a Veo API are not trying to learn Google Cloud. They want to send a prompt and get an MP4 back. This page lays out what the direct route asks of you, what changes when you call Veo through a gateway, and the cases where going direct to Google is still the better choice.

What the direct route typically involves

Google exposes Veo through its own platforms, and the exact setup depends on which one you choose and changes over time, so treat the list below as the general shape and confirm the specifics in Google's current documentation. For the enterprise-style route (Vertex AI) you should expect most of the following:

1. A cloud project with billing attached. Generation is charged to a billing account, so someone with the right permissions has to create and fund it.
2. The relevant API enabled on that project, plus a region choice, since model availability can differ by region.
3. Identity and access management. A service account with a role that allows prediction calls, and a way to get credentials to wherever your code runs (key files, workload identity, or application default credentials locally).
4. Quota awareness. Video generation is heavy, and per-project, per-region limits apply. Raising them can mean a request and a wait.
5. Long-running operation handling. Video jobs are asynchronous. You start an operation, poll it, and then fetch the result, which may be delivered to storage you also have to configure.

None of this is unreasonable for a team that already lives in that ecosystem. It is real overhead for a small team, a prototype, or a product whose main stack is somewhere else.

What changes with a gateway

Through VideoRouter the integration surface collapses to one API key and one HTTP endpoint. There is no project to create, no service account to mint, and no per-model quota request on your side. Veo is just a model id:

curl https://videorouter.sh/api/v1/videos \
  -H "Authorization: Bearer llmr_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"model": "google/veo-3.1-fast", "prompt": "a lighthouse beam sweeping across a foggy harbor", "duration_secs": 8}'

The response is a job. Its status moves queued, in_progress, then completed or failed, and you poll GET /videos/{id} until it finishes. Polling is free. The finished job carries the video URL in data[0].url. Errors use the OpenAI-style {"error": {"message", "type", "code"}} envelope, so the error handling you wrote for any other API mostly carries over.

A side-by-side comparison

The part people miss: Google is still one of the hosts

Skipping the cloud setup does not mean skipping Google's infrastructure. Google appears as one host among several on the Veo model pages, and the others resell the same model at their own prices. Unpinned requests go to the cheapest healthy host and fail over down the list if a submission is rejected. If you want a particular host, add it to the model id, for example google/veo-3.1/google. Note that this suffix is a soft preference: the platform tries that host first and still falls back to the rest of the pool if it errors. For a hard pin with no fallback, use "provider": {"only": ["google"], "allow_fallbacks": false}. The model pages list every host and the live price per resolution, and the pricing page shows the spread.

When going direct is still right

• Your company already runs on that cloud and has the project, billing and compliance review done. The marginal setup cost is near zero and a single invoice may matter to finance.
• You need a contractual relationship with the model creator (support terms, data-processing agreements, region residency). Pin the Google host and review its terms. A gateway does not replace that conversation.
• You need features the gateway has not wired for a given model. The gateway exposes a normalized request shape; a provider's newest options can appear there later than in the provider's own API.

If none of those apply, the gateway route costs you less time and still lets you point at Google when you want to.

Practical notes before you ship

• Use the three variants deliberately. google/veo-3.1, google/veo-3.1-fast and google/veo-3.1-lite share one request shape. See the cost-strategy guide for how to use them together.
• Resolution and aspect ratio are best-effort. Per the video docs, an unsupported combination is ignored rather than rejected, and some hosts ignore both fields. Check the dimensions of what you get back instead of assuming.
• Lock down the key. A key can carry a model allow-list and a monthly spend cap, which gives you a safety net that a shared cloud credential usually does not.
• Do not hold the file hostage to a URL. Copy completed videos to your own storage once a job finishes.

The quickstart has a complete create-poll-download script, and you can create a key at videorouter.sh/signup.

Frequently asked questions

Keep reading

• Veo 3.1 vs Veo 3.1 Fast vs Lite — Which to Call from Your API
• Veo 3.1 Image-to-Video API: Request Shape and Workflow
• Veo 3.1 Cost Control: Drafts, Caching and Tier Gating
• How to Call the Veo 3.1 API: curl, Python and Error Handling