Vercel's 300 s default: does a 30 s Sume image sync call fit?

A Vercel function with fluid compute has a default duration of 300 seconds, so a synchronous POST /v1/images call to Sume, which waits at most 30 seconds, fits inside it with room to spare. You do not need to raise maxDuration for the image route. You do still need to handle the 202 that the route returns when the wait runs out, because a 4K, high-quality or large n request can take longer than 30 seconds and falls back to a job envelope.

Video is different. A video job can run for minutes, and Vercel's own ceiling for a function is 300 seconds on Hobby and 800 seconds on Pro and Enterprise, so a route that holds the connection open until a video finishes is the wrong shape. Submit, return the job id, and let a poll or a webhook finish the work.

The numbers side by side

The duration page also lists an Extended 1800 second option in beta for Pro and Enterprise, and says durations above 800 seconds must be set per function. That beta is a poor reason to hold a request open for a render; a stored job id costs nothing and survives a redeploy. The figures below were read from the Vercel page and the Sume image docs today.

Steps

• Keep the Sume key on the server. The route handler below reads it from SUME_API_KEY.
• Set wait_timeout_seconds a little under the ceiling, here 25, and set a client timeout above it, here 40 seconds, so the Sume response arrives before your client gives up.
• Send an Idempotency-Key from your order id. If the browser retries the request, you get the original job.
• Return 200 with images, 202 with the status URL, and 502 with Sume's error code and next_action for a failed job.
• For videos, skip sync mode and poll GET /v1/jobs/{id}/status from a cron or queue.

Route handler

It works in a Next.js route file or any runtime that supports the Web Request and Response objects. The maxDuration line is optional; drop it to accept the default.

export const maxDuration = 60; // seconds; the default with fluid compute is 300

export async function POST(request) {
  const { prompt } = await request.json();
  const res = await fetch(`${process.env.SUME_BASE ?? "https://api.sume.com"}/v1/images`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.SUME_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": request.headers.get("x-order-key") ?? crypto.randomUUID(),
    },
    body: JSON.stringify({ model: "sume/auto", prompt, mode: "sync", wait_timeout_seconds: 25 }),
    signal: AbortSignal.timeout(40_000),
  });
  const doc = await res.json();
  if (res.status === 200) return Response.json({ done: true, images: doc.data });
  if (res.status === 202) return Response.json({ done: false, poll: doc.data?.status_url }, { status: 202 });
  return Response.json({ error: doc.error?.code ?? "upstream_error", next: doc.error?.next_action }, { status: 502 });
}

What Sume does not do

Sume does not know where your function runs and will not shorten a response to match it. A timed-out wait is not a failed job, and you should not resubmit it without the same Idempotency-Key. For longer waits, see the jobs and results docs. Check your own plan's limits on the Vercel page before relying on the figures above.