Poll many transcription jobs without a 429: next_poll_after_seconds

When you poll Sume transcription jobs over REST, sleep for the next_poll_after_seconds in the last response, fall back to exponential backoff when it is absent, and stop as soon as terminal is true. On 429 rate_limited, wait for the retry-after header and keep the job ids you already hold. Do not submit a new paid job because a poll failed. These rules are in Jobs and results and Errors and rate limits, read 2026-10-06.

Fields to read on every poll

The envelope tells you what to do next, so you do not need to guess an interval.

A poll loop for one job

Run one loop per job id from a worker pool, or loop over the pending set in a single thread with a shared sleep. Cap the number of status calls you make per second so a large batch does not trip the abuse limit.

import os, time, requests

API = "https://api.sume.com"
H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}


def wait_job(job_id, max_seconds=300):
    deadline = time.time() + max_seconds
    delay = 2.0
    while time.time() < deadline:
        r = requests.get(f"{API}/v1/jobs/{job_id}/status", headers=H, timeout=30)
        if r.status_code == 429:
            time.sleep(float(r.headers.get("retry-after", delay)))
            continue
        r.raise_for_status()
        body = r.json()
        job = body.get("data", body)
        if job.get("terminal"):
            return job
        delay = float(job.get("next_poll_after_seconds") or min(delay * 2, 30))
        time.sleep(delay)
    return None

When polling is the wrong tool

For a large batch, a webhook_url on the submit removes polling entirely. For agent clients, the hosted MCP can wait on up to 20 jobs in one call; see jobs_wait for 20 jobs.