GuidesAPI Reference
Guides

Explore experimental features

Sometimes, a feature may undergo multiple iterations before it becomes clear and easy to use, ensuring a stable and high-performing product for you. During this phase, your feedback is invaluable to us as it helps us refine our offerings and deliver a well-defined API and valuable features tailored to your needs.

Hence, we are committed to providing access to experimental features while ensuring transparency. Any unstable or experimental features will be clearly marked, allowing you to explore new functionalities while understanding their developmental status.

Maturity levelAPI stabilityFeature maturityDev Guide descriptionOpenAPI attributeOpenAPI description
ALPHAunstable - breaking changes allowedNo SLA, not safe for production"ALPHA" tagged features are in mid-stage development. They can change or in rare cases be removed. No backward compatibility is guaranteed nor bug service level agreement (SLA) do apply. Customers using ALPHA features are advised not use them in production.x-maturity: alphadescription: ALPHA ...
BETAstableNo SLA, safe for production but has limitations"BETA" tagged features are in end-stage development. They are backward compatible and can not be removed. They have no major bug, but coverage, quality, performance, or test coverage is not considered final. Customers can safely use BETA features in their applications if they accept those limitations and potential behavior refinements.x-maturity: betadescription: BETA ...

Example:

    VehicleMinStopsCountLimit:
      x-maturity: alpha
      description: |
        **ALPHA** Hard limit on the minimum number of stops in a shift.
        Please consult the developer guide for more information before using this feature. 
        To enable it, add `minStops` flag to `experimentalFeatures` configuration in the problem.
      type: object

Enabling experimental feature

To enable an experimental feature, add an experimentalFeatures array to the problem configuration, containing the names of the features you wish to enable.

{
  "configuration": {
    "experimentalFeatures": [
      "experimentalFeature1",
      "experimentalFeature2"
    ]
  },
  "fleet": {},
  "plan": {}
}

In case of incorrect feature flag, validation error would be returned:

{
    "title": "BAD_REQUEST",
    "status": 400,
    "code": "E613500",
    "cause": "Unsupported experimental feature flag \"wrongFeatureFlag\".",
    "action": "",
    "correlationId": ""
}

Currently supported experimental (alpha) feature flags:

Feature flagDescription
minStopsallows to define minimum amount of stops vehicle should serve in one shift. For more information, see Fleet.
restTimesallows to define breaks depending on duty time.
clusterNearbyallows to define how the stops are created and cluster nearby activities. For more information, see Fleet.
advancedObjectivesallows to define advanced objective functions. For more information, see Advanced Objectives.
softTimeWindowsallows to define time-windows that can be violated to a certain extent, if this leads to better solutions overall. For more information, see Soft Time Windows.
houseKeysallows to control the service duration of multiple jobs served at the same customer location. For more information, see Customer-based service duration.
rechargesallows to define EV recharge points. For more information, see Fleet.
excessCostsallows specifying costs that should only apply when certain limits are exceeded.
flexibleGroupsallows to define flexible groups of jobs that can be served anywhere in the tour but only with one vehicle. For more information, see Job Groups & PUDOs.
ignoreTrafficViolationsallows to ignore traffic violations when calculating the route. For more information, see Fleet.
parkingIdsallows to specify parking places on jobs.
multipleUnassignedReasonsallows to get multiple unassignment reasons for unassigned jobs.