Skip to main content
There is no dedicated “re-optimize now” endpoint. A running plan is always subject to re-optimization the moment its data changes — see Continuous and interactive optimization. Reacting to a disruption is a matter of updating the right part of the plan, not calling a separate recalculation API.

​
Types of triggering disruptions

Every one of these is the same operation: mutate the relevant part of your local copy of the plan, then PUT the whole plan back — there is no endpoint that targets a single resource or order in isolation anymore.

​
How this differs from a full recalculation

Submitting any of the updates above keeps the plan’s id unchanged, so it isn’t treated as a new problem: the engine degrades the previous solution only as much as needed to stay valid for the new data, then keeps improving from there — it does not restart optimization from scratch. This is normally much faster than the plan’s original optimization, which had to learn the problem’s shape for the first time. If an older version of the plan is still optimizing when a disruption update lands, the engine drops the stale version in favor of the newest one — you never get two versions “optimized” at once.

​
Best practices for call frequency

  • Batch disruptions that arrive close together into a single update where possible, rather than issuing one PUT per individual change — every update re-triggers optimization, and back-to-back updates just cause the engine to keep abandoning a version it hasn’t finished with yet.
  • Poll before you push another update. Check the plan’s status (see How the optimization engine works) to see whether the previous update has already settled; there’s little value in sending a new disruption update while the engine is still mid-search on the last one, beyond the disruption itself needing to be reflected immediately.
  • Don’t reduce maxOptimizationDuration for these updates just because they feel like small edits — the field caps this version’s remaining search time, and a busy fleet mid-shift can still take real time to re-settle around a disruption; size it the same way you would for the initial plan (see Handling large volumes).

​
See also

  • How the optimization engine works — what happens when a plan is updated with the same id, and the three integration patterns for retrieving a solution.
  • Handling infeasibility — diagnosing a disruption that leaves a stop unplannable rather than just delayed.
  • Data model — full field reference for Resource and Order, the two objects most commonly touched by a disruption.