Polling and backoff¶

~4 min · Operations

Since retrieval is a poll, make the loop resilient: don't hammer the API, and give up gracefully.

A robust loop¶

import time, requests

BASE = "https://iq.scheduledroutes.ddswireless.net"
headers = {"Authorization": "Bearer YOUR_API_KEY"}

def get_solution(optimization_id, timeout_s=120):
    interval = 1.5                 # start polling after a short pause
    deadline = time.time() + timeout_s
    while time.time() < deadline:
        r = requests.get(f"{BASE}/raas/optimization/{optimization_id}", headers=headers)
        if r.status_code == 200:
            return r.json()["solution"]
        if r.status_code == 202:
            time.sleep(interval)
            interval = min(interval * 1.5, 10)   # exponential-ish backoff, capped at 10s
            continue
        r.raise_for_status()       # 4xx/5xx — stop and surface the error
    raise TimeoutError(f"Solve did not complete within {timeout_s}s")

Guidelines¶

First poll: wait ~1–2 seconds — tiny problems are near-instant, but not synchronous.
Interval: steady 2s is fine for small problems; back off (up to ~10s) for large ones.
Cap the total wait with a timeout so a stuck job doesn't loop forever.
On 429: back off harder before the next poll (see Rate limits).
On 4xx/5xx: stop polling and handle the error — the solve won't recover on its own.

Match the interval to the problem size

A 20-stop problem returns in seconds; a several-hundred-vehicle problem takes longer. Bigger problem → longer first delay and interval.

Related: Status codes · Rate limits and errors · Quickstart