Skip to main content
Version: v0.2b

Update Stops from a live Plan

Here we will be using the Update Live Stop, the Re-Optimize Plan, and the Re-Distribute Plan endpoints to update a Stop from a Plan that was already optimized, and therefore not editable via the Update Stop endpoint.

# We update the stop using the liveUpdate method
curl https://api.getcircuit.com/public/v0.2b/plans/KBoYtDxO3FMh7zJkWdU3/stops/vgsTiQi85ueWRs1JnXx7:liveUpdate \
-X POST \
-H 'Content-Type: application/json' \
-d '{"notes": "Update notes", "timing": {"earliestAttemptTime": {"hour": 12, "minute": 0}}}' \
-u <your-api-key>:

# With stop updated, we start the re-optimization (we
# are considering a plan with the id plans/KBoYtDxO3FMh7zJkWdU3 here):
curl https://api.getcircuit.com/public/v0.2b/plans/KBoYtDxO3FMh7zJkWdU3:reoptimize \
-X POST \
-H 'Content-Type: application/json' \
-d '{}' \
-u <your-api-key>:

# The response will return an operation object similar to the following:
# {
# "id": "operations/FQ95Ex714KYeojkeIm77",
# "done": false,
# "type": "plan_optimization",
# ...
# }
#
# Why an operation? Because the optimization can take a long while to finish, so
# we process it in an asynchronous manner.

# Now, with the returned ID, we can periodically call the GET operation endpoint
# to check it until the `done` field is `true`
curl https://api.getcircuit.com/public/v0.2b/operations/FQ95Ex714KYeojkeIm77 \
-u <your-api-key>:

# Now wait until the operation is done, which means it finished processing, and
# it might have had a successful result or an error one.
#
# The error one will have the `result.code` and `result.message` fields set,
# while the successful one will have the result fields, which include the
# skipped stops and the amount of optimized stops.

# Now finally we can re-distribute this plan and thus apply the changes to the stop that was
# performed before
curl https://api.getcircuit.com/public/v0.2b/plans/KBoYtDxO3FMh7zJkWdU3:redistribute \
-X POST \
-u <your-api-key>: