Input validation

Whenever you submit a dataset to Timefold through the API or UI the input is validated and if there are issues, you will see the following depending on the type of validation issue:

Invalid JSON

The submitted JSON file is validated to make sure the JSON is syntactically valid and valid according to the OpenAPI specification and can be processed by Timefold.

A POST call with an invalid JSON document will return a status 400 Bad Request. The response will include a message specifying the input JSON has an invalid format and details that will help you locate the issue with the JSON.

Solution: Fix the invalid JSON and resubmit the dataset.

Validation errors

The JSON is valid according to the OpenAPI specification but the submitted dataset includes (or does not include) elements that need to be rectified before the dataset can be solved.

The dataset’s state will clearly indicate that it is invalid.

Validation errors include:

  1. A visit time window does not have a minStartTime that is less than or equal to the maxStartTime or maxEndTime.

  2. A floating break does not have a minStartTime plus duration that is less than or equal to the maxEndTime.

  3. A fixed break does not have a startTime less than or equal to the endTime.

  4. A break starts before its shift minStartTime.

  5. A vehicle shift must have either a minStartTime or a minFirstVisitArrivalTime.

  6. A visit dependency must reference an existing preceding visit id.

  7. A visit group must have at least two visits.

Solution: Review the error message and resubmit the dataset.

Validation warnings

The JSON is valid according to the OpenAPI specification but there are some recoverable problems.

The dataset’s state will indicate its valid and the dataset can be solved.

Validation warnings include:

  1. Uses a deprecated feature.

  2. Is missing some element that is necessary to successfully assign a visit, including:

    1. Technician ratings are defined for vehicles, but the model config does not enable the technician ratings constraint.

    2. There is a deprecated priority in a visit.

    3. The list of vehicles is empty.

    4. The list of vehicle shifts is empty.

    5. A vehicle shift should have a maxSoftTravelTime that is less or equal to maxTravelTime.

    6. The time window is too small for the visit’s specified duration.

    7. All time windows of a visit start after the latestSlaEndTime.

    8. A visit’s 'preferredVehicles' references a non-existing vehicle.

    9. A visit’s 'prohibitedVehicles' references a non-existing vehicle.

    10. A visit requires a tag that is not declared by any vehicle shift. This visit cannot be assigned to any vehicle shift.

    11. A visit requires a skill that is not declared by any vehicle shift. This visit cannot be assigned to any vehicle shift.

Solution: The dataset will be processed, but we recommend looking at the warnings and updating the dataset.

Machine-readable validation results

In addition to human-readable validation messages, Timefold provides machine-readable validation results through the API. Each validation issue includes a unique code, severity level, and structured details about the affected entities. This makes it easy to programmatically detect and handle validation issues in your data pipelines.

Retrieving validation results

After submitting a dataset, once the dataset lifecycle has progressed past the DATASET_VALIDATED or DATASET_INVALID status, you can retrieve the validation results by calling this endpoint:

GET /v1/route-plans/<ID>/validation-result

The response includes a status field (ERRORS, WARNINGS, or OK) and an issues array. Each issue has:

  • id: a numeric identifier for the issue within the dataset.

  • code: a machine-readable code identifying the type of issue.

  • severity: either ERROR or WARNING.

  • detail: a structured object with fields identifying the affected entity (e.g. the vehicle shift or visit ID, time windows) and a type field indicating the entity type.

{
  "status": "ERRORS",
  "issues": [
    {
      "id": 1,
      "code": "<ISSUE_TYPE_CODE>",
      "severity": "ERROR",
      "detail": {
        "<entityId>": "<ID>",
        "type": "<ENTITY_TYPE>"
      }
    },
    {
      "id": 2,
      "code": "<ISSUE_TYPE_CODE>",
      "severity": "WARNING",
      "detail": {
        "<entityId>": "<ID>",
        "<extraProperty1>": "<extraValue1>",
        "type": "<ENTITY_TYPE>"
      }
    }
  ]
}

The code field contains a machine-readable identifier. The detail object varies per issue type and includes the IDs and properties of the affected entities.

Validation issue types

Listing validation issue types

To see all validation issue types supported by the model, use:

GET /v1/route-plans/validation-issue-types

To look up a specific issue type by its code:

GET /v1/route-plans/validation-issue-types/<CODE>

Examples of validation issue details

The detail object provides different data depending on the issue type. Below are examples of what the detail object looks like for specific validation issues.

A visit that refers to a skill not declared on any vehicle shift produces a detail with a visitId and skillName:

{
  "id": 1,
  "code": "VISIT_REQUIRED_SKILL_MISSING",
  "severity": "ERROR",
  "detail": {
    "visitId": "Beth",
    "skillName": "electrical",
    "type": "VISIT_SKILL"
  }
}

A vehicle shift missing its start time produces a detail with a vehicleShiftId:

{
  "id": 2,
  "code": "VEHICLE_SHIFT_START_TIME_MISSING",
  "severity": "ERROR",
  "detail": {
    "vehicleShiftId": "Carl-Monday",
    "type": "VEHICLE_SHIFT"
  }
}

Recommended usage patterns

Automated error mitigation

Use the code and detail fields to implement targeted mitigations for specific validation issues. For example, if a visit fails validation because its start time is after its end time, your pipeline could automatically remove that visit from the dataset and resubmit.

A typical flow looks like this:

  1. Submit a dataset.

  2. Retrieve the validation result.

  3. If the status is ERRORS, iterate over the issues.

  4. For each issue code, apply a specific mitigation if one exists (e.g. remove the entity, correct values, add a missing field).

  5. Resubmit the corrected dataset.

Monitoring for new validation issue types

Periodically call the validation issue types endpoint to check whether the model supports new issue types that your pipeline doesn’t handle yet. This helps you stay ahead of unhandled validation issues as the model evolves.

For example, you could add a scheduled check to your CI/CD pipeline that compares the list of known issue codes against the current response from the validation issue types endpoint. If a new code appears, flag it for your team to implement a mitigation or acknowledge it.

Input validation in the Timefold Platform UI

In addition to the API-based validation described above, the Timefold Platform UI also provides built-in support to help you detect and manage input validation issues when working with datasets.

Invalid JSON

When uploading an input file through the New plan dialog in the Timefold Platform UI:

  • If the JSON is invalid, the upload is immediately rejected.

  • The dialog displays a clear error message to help you locate and fix the issue.

  • The dataset is not accepted until the JSON syntax is corrected.

This ensures that invalid JSON never enters the system.

Validation errors

Datasets (submitted via the UI or API) that are syntactically valid but contain validation errors:

  • The dataset is accepted and appears in the list of datasets.

  • Its state clearly indicates that it is invalid.

  • Clicking on the dataset opens the detail page, where you can see a complete list of validation errors.

You can also use the Timefold Platform UI to filter datasets by their state, making it easy to find all invalid datasets. This allows teams to quickly identify and fix problematic inputs.

Validation warnings

Datasets (submitted via the UI or API) that are syntactically valid but contain validation warnings:

  • The dataset is accepted.

  • The model can still solve successfully.

  • All standard dataset results are available, including metrics, optimization gain, and score analysis.

On the dataset detail page, the list of validation warnings is shown below the score analysis table, making it easy to review non-blocking issues while still analyzing optimization results.

Next