Async optimisation. Returns 200 immediately with a Plan id and an optimisation job id. The optimisation runs in the background; poll GET /plans/{id} to check progress.

Initial response: { "optimisation": { "id": "<uuid>", "in_progress": true }, "plan": { "id": <integer>, "dispatched": false } }

Polling — GET /plans/{id}:

• Completed: plan.routes is non-empty (or plan.unserved is non-empty if no routes are viable). Either signals the optimisation has finished.
• Still running: plan.routes and plan.unserved are both empty.
• Failed: there is no terminal failure signal on the Plan resource today. A failed job leaves the Plan in the same "empty arrays" state as a still-running job. Implement a client-side hard timeout — recommended 10 minutes — after which the job should be considered abandoned.

Recommended polling cadence:

• First minute: every 2 seconds.
• After 1 minute: every 10 seconds, exponential backoff up to 30 seconds.
• Hard timeout: 10 minutes total.

Webhook coupling: the plans.created webhook fires immediately after the Plan is persisted — before the optimisation job has completed. A webhook delivery does not imply the optimisation finished. Consumers receiving plans.created should still poll GET /plans/{id} to learn the outcome.

Concurrency limits per depot (queue, not timeout): STANDARD 100, LONG 100, DIST 7, BOOKING_CHECK 1. No documented per-job timeout; typical jobs complete in 5–30 seconds.

Idempotency: Supports the idempotency-key request header for safe retries. See the Idempotency section in the API description.