Route Optimization OptiFlow API - Api Changes 1.42.0 (26.01.2026)

[Bernd Welter]

Api	VarVersion	Type	Date	Description
Route Optimization OptiFlow API	1.42.0	FEATURE	26.01.2026	Added a rule for adjusting task duration based on task and/or vehicle categories.
Route Optimization OptiFlow API	1.42.0	IMPROVEMENT	26.01.2026	Increased maximum number of categories to 100.

[Bernd Welter]

No endpoint changes (same /optimizations and related operations), but request/DTO capabilities expanded:

• New “task rules” feature under rules.tasks (conditional duration modifiers for tasks).
• Category lists got bigger: several categories arrays increased from maxItems: 50 → 100 (vehicles, tasks, depots, resources, orders, locations, compartments).
• Minor doc-text tweak (whitespace in a description) — no behavioral impact.

1) New: rules.tasks (Task Rules)
What changed?

• In v1.41, the Rules object only supported rules.locations.
• In v1.42, Rules additionally supports rules.tasks as a list of task rules.

What is a Task Rule?

A TaskRule lets you conditionally modify task duration via a DurationModifier.

Each rule has:

• conditions (OR-list; each condition is an AND-match)
• duration (DurationModifier)

Conditions can match on:

• taskCategory
• vehicleCategory

Why it matters

This is a nice modeling upgrade if your service times depend on context, e.g.:

• “Forklift-needed stops take +10 minutes”
• “Big trucks are slower to handle at customer locations”
• “Special handling categories increase service time”

Example (request snippet)

Code: Select all

{
  "rules": {
    "tasks": [
      {
        "conditions": [
          { "taskCategory": "FORK_LIFT_NEEDED" },
          { "vehicleCategory": "BIG_TRUCK" }
        ],
        "duration": { "factor": 1.0, "extra": 600 }
      }
    ]
  }
}

(Structure based on Rules.tasks + TaskRule + TaskRuleCondition + DurationModifier.)

Compatibility note: This is an additive change. Existing clients should keep working; clients with strict validation/generation may need updated models to accept rules.tasks.

2) Bigger categories arrays (50 → 100)

Several schemas now allow up to 100 categories instead of 50.

Concrete example:

• v1.41 ServiceOrderProperties.categories had maxItems: 50.
• v1.42 Vehicle.categories has maxItems: 100.
• v1.42 TaskProperties.categories has maxItems: 100.
• v1.42 Resource.categories has maxItems: 100.

Impact

• Usually non-breaking (it relaxes constraints).
• But if you have client-side validators hard-coded to 50, you may want to bump those limits.
• If you store categories in a DB column with limited size, this might increase payload sizes and storage needs.

3) Endpoints / Operations

I didn’t see any changes to the API surface (paths/operations look consistent between 1.41 and 1.42; the version bump is in the spec metadata).

Suggested action items (practical)

• Update OpenAPI-generated client/server models to include rules.tasks, TaskRule, TaskRuleCondition.
• If you validate categories length client-side, increase allowed max to 100 (where applicable).
• Consider adding a small sample in your integration tests that includes rules.tasks (optional) to ensure forward compatibility.