Vercel rewrite to an external API times out at 120 seconds
Vercel proxied rewrites to an external destination time out at 120 seconds with ROUTER_EXTERNAL_TARGET_ERROR. A Sume async submit returns at once.

Any Sume call that answers within 120 seconds survives a Vercel proxied rewrite, and an async submit answers with 202 immediately, so it fits. Vercel's limits page says the maximum timeout for proxied requests to an external destination is 120 seconds, and a timeout returns ROUTER_EXTERNAL_TARGET_ERROR.
Sume behavior is from the Jobs and results docs; the Vercel text was read 2026-09-30.
What does Vercel say?
The page reads: “The maximum timeout is 120 seconds (2 minutes)” for proxied requests, meaning rewrites or routes with an external destination. On timeout, an error with the message ROUTER_EXTERNAL_TARGET_ERROR is returned. The limits page was marked last updated 2026-09-16.
| Call | Wait | Under 120 s? |
|---|---|---|
| Async submit | Returns 202 at once | Yes |
| Status or result GET | One quick request | Yes |
| Sync or subscribe | At most 30 seconds | Yes |
| Holding a request until the job ends | Not bounded by Sume | Not guaranteed |
Should the browser call Sume through a rewrite?
The API key must stay out of browser code. Put the submit in a server route that reads SUME_API_KEY from the environment and returns the job id to the browser.
What if the proxy times out mid-request?
The submit may already have been accepted. Retry with the same Idempotency-Key so you get the original job back instead of a second paid one. A different payload under the same key is a 409 idempotency_conflict.
How does the client follow the job?
Keep the job id and poll status_url, using next_poll_after_seconds when it is present. Each poll is a short request, well inside the proxy limit.
Sources
Related posts
More in Developers
- Video 1.0 4k resolution error: only 720p and 1080p on that URL
Video 1.0 accepts 720p (default) and 1080p from its legacy vocabulary and rejects 4k. For 4K send a sume/auto request to POST /v1/videos instead.
- Video 1.0 bitrate_mode: still in the shape, rejected by Auto
bitrate_mode is retained in Video 1.0's legacy request shape but Auto rejects it. Omit it, and note that Gemini Omni Flash 1.1 has no bitrate_mode either.
- Video 1.0 duration vs duration_seconds: what if they differ?
Video 1.0 accepts duration and its alias duration_seconds. If you send both they must agree; the value is checked against the Auto serving family.
- Video 1.0 last frame: end_image_url needs image_url first
To set a last frame on Video 1.0, send end_image_url together with image_url. The docs list the modes: text, first frame, start and end frames, references.
Written by Sume