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 driver shift must have either a minStartTime or a minFirstStopArrivalTime.

  2. A driver shift must have a minStartTime before or equal to minFirstStopArrivalTime (when both are set).

  3. A driver shift itinerary contains a stop that is not found in the route plan.

  4. The list of jobs is empty.

  5. A job’s requiredDrivers references a non-existing driver.

  6. A stop’s time window does not have minStartTime less than the maxEndTime.

  7. Stops of the same job are pinned to different shifts.

  8. A stop’s dependency must reference an existing preceding stop id.

  9. The sum of the demands for a capacity type of a job does not equal zero.

  10. A job with a single stop or with more than two stops has a demand definition at the job level.

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 stop, including:

    1. The list of drivers is empty.

    2. The list of driver shifts is empty.

    3. A job’s 'preferredDrivers' references a non-existing driver.

    4. A time window is too small for a stop.

    5. A job requires a skill that is not declared by any driver shift.

    6. The demand definition at the job level is different than the demand definition at the stop level for a job with two stops (e.g. different quantities, different types).

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/{model-api-collection}/<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.

  • potentially extra properties identifying the affected entity (e.g. the {entities-resource} or {entities-work-item} ID, time windows) and a type field indicating the entity type.

{
  "status": "ERRORS",
  "issues": [
    {
      "code": "<ISSUE_TYPE_CODE>",
      "severity": "ERROR",
      "<entityId>": "<ID>"
    },
    {
      "code": "<ISSUE_TYPE_CODE>",
      "severity": "WARNING",
      "<entityId>": "<ID>",
      "<extraProperty1>": "<extraValue1>"
    }
  ]
}

The code field contains a machine-readable identifier. The object can vary per issue type to include 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/{model-api-collection}/validation-issue-types

To look up a specific issue type by its code:

GET /v1/{model-api-collection}/validation-issue-types/<CODE>

Examples of validation issue details

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

A job that refers to a skill not declared on any driver shift produces a response with a jobId and skillName:

{
  "id": 1,
  "code": "JOB_SKILL_NOT_OFFERED_BY_ANY_SHIFT",
  "severity": "WARNING",
  "jobId": "jobA",
  "skillName": "first-aid"
}

A driver shift missing its start time produces a response with a driverShiftId:

{
  "id": 2,
  "code": "DRIVER_SHIFT_MISSING_START_TIME",
  "severity": "ERROR",
  "driverShiftId": "Carl-Monday"
}

Recommended usage patterns

Automated error mitigation

Use the code and other fields to implement targeted mitigations for specific validation issues. For example, if a {entities-work-item} fails validation because its start time is after its end time, your pipeline could automatically remove that {entities-work-item} 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.

The screenshot below shows an example from Field Service Routing, where five errors of three types were detected. Other models will show different validation error types specific to their domain.

Platform UI showing a dataset in the invalid state with a list of five validation errors in three types

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.

The screenshot below shows an example from Field Service Routing, where one warning of one type is listed beneath the score analysis table. Other models will show different validation warning types specific to their domain.

Platform UI showing the score analysis table with 1 validation warning listed below it

Next