Planning API Changelog

• Added extra documentation for the [EXPERIMENTAL] location-rule-set endpoints

• Stricter validation for excluded_stop_locations.labels in the vehicle-stop-rule-sets endpoint

• Allow empty arrays for break_rule_groups, depots, charging_locations, and location_rules in their respective sets.

• Clarify that CursorPage responses always have a data and a cursors field.

• Added POST endpoints for creating resources without requiring a client-provided ID for:
  • depot-sets
  • charging-location-sets
  • location-rule-sets
  • break-rule-sets
  • vehicle-stop-rule-sets
  • plan-profiles

• Allow empty rules array in vehicle-stop-rule-sets
• Clarify that combining ALL with other conditions is not allowed

• Introduction of [EXPERIMENTAL] vehicle-stop-rule-set endpoints
• Add vehicle_stop_rule_set_id to Plan Profiles.

• Updated the [EXPERIMENTAL] location-rule-set endpoints to use an Operator.ALL instead of an empty condition when targeting all locations

• Introduction of [EXPERIMENTAL] location-rule-set endpoints
• Add location_rule_set_id to Plan Profiles.

• Make charges field required under Stop

• Add charges for EVs to the release API

• Set maximum allowed characters to 200 for ids in plan profile related API schemas and requests.

• Marked charging location sets as Early Access.

• Rename business_id fields to id in plan profile related API schemas and requests.

• Clarified descriptions of location_business_ids from location workload leveling sets and charging locations business_id

• Add alternative property for Route.resource_combination: Route.vehicle.

We are no longer using resource combination as the name for the entity that is sent from Resource Management to OptiFlow match. This backwards compatible change in the release API reflects this: a route has vehicles, not resource combinations.

• Added endpoints for managing plan profiles
• Limit the amount of charging stations to 1 for a charging location

• Removed location_id from ChargingLocation
• Removed business_id from ChargingStation

• Added endpoints for managing charging location sets
• Introduced consistent validation pattern for business_id parameters across all endpoints

• For location workload levelling set - mark business_id as read-only
• For break rules - align response headers, status codes and request bodies with our API guidelines + document validation rules
  • As this API is marked as EXPERIMENTAL we did not consider this a breaking change

• Rename cursor to cursors for the list endpoint of break rule sets and depot sets
  • As these APIs are marked as EXPERIMENTAL we did not consider this a breaking change

• Only expose next cursor for break rule sets and depot sets
  • As these APIs are marked as EXPERIMENTAL we did not consider this a breaking change

• Added endpoints for managing break rule sets

• Added endpoints for managing depot sets

• Add Location header when creating a new location workload levelling set

• Added endpoints for managing order-order restriction sets

• Added endpoint for retrieving location workload levelling sets:
  • GET /planning/v1/settings/location-workload-levelling-sets

• rename security scheme

• Added endpoints for managing location workload levelling sets:
  • GET /planning/v1/settings/location-workload-levelling-sets/{business_id}
  • PUT /planning/v1/settings/location-workload-levelling-sets/{business_id}
  • DELETE /planning/v1/settings/location-workload-levelling-sets/{business_id}

• GET /planning/v1/plannings now also shows the planning name and planning labels.
• The following endpoints are marked for removal on 30/06/2025. More information on how to migrate can be found here.
  • GET /planning/v0/releases
  • GET /planning/v0/plannings/{id}/releases/latest

• The following endpoints are marked for removal on 30/06/2025. More information on how to migrate can be found here.
  • GET /planning/v0/releases
  • GET /planning/v0/plannings/{id}/releases/latest
• The following v0 endpoints will remain supported for now, even after 30/06/2025, until further notice:
  • GET /planning/v0/ping > Will be kept for convenience as long as there are v0 endpoints available.
  • GET /planning/v0/plannings/{id}/export > No alternative in v1. No excel export will be created in v1 and onwards. These will be replaced with alternative endpoints in the future that will fulfill the same needs.
  • GET /planning/v0/plannings > Although this endpoint will still be available until further notice, we strongly suggest you already migrate to the newer GET /planning/v1/plannings. Please contact us, if the newer endpoint does not fulfill your needs.
• Upgraded some endpoints from v0 to v1:
  • GET /planning/v0/ping has been superseded by GET /planning/v1/ping. No changes were made to the API contract.
  • GET /planning/v0/plannings has been superseded by GET /planning/v1/plannings. Note that the response body has been changed significantly from the v0 endpoint.
  • GET /planning/v0/releases has been deprecated in favor of GET /planning/v1/plannings?released_since={date-time}. The response body contains small changes compared to the v0 endpoint.
  • GET /planning/v0/plannings/{id}/releases/latest has been deprecated in favor of GET /planning/v1/plannings/{id}/releases/latest. This introduces the concept of routes with multiple trips. Note that this changes the response body of the endpoint significantly compared to the v0 endpoint.