Skip to main content

Upload Data

The initial step in utilizing PayrollDetect is to upload a dataset of historical payroll data.

Upload only approved payslips

Our machine learning model learns what patterns are considered normal based on historical data. That is why it makes sense to upload only approved data, as they represent the actual payroll pattern for an employee.

Best Practices for Data Upload

When uploading data via our API, it's crucial to either upload only new data or use consistent payslipIds to avoid duplication and unnecessary database growth. This ensures efficient processing and prevents the system from treating existing records as new entries. More on this in Core Concepts

The procedure for data uploading is as follows:

  1. Get Presigned URL: Call GET /presigned_url with the Client ID and Tenant ID in the header. The Tenant ID is set by you and should be the same as your client_id for the API integration. You will receive a presigned url and a Job ID in response.
GET /presigned_url
curl -X GET "https://api.machine-learning-factory.stage.visma.com/pd/presigned_url" \
   -H "Authorization: Bearer YOUR ACCESS TOKEN" \
   -H "tenantId: YOUR_TENANT_ID"

Remove .stage from base url for production environment.

  1. Create JSON File: Formulate a JSON file containing the Datasets with payroll data, adhering to the request body of PUT /[presigned url].
Request payload format
One of
required
Array of objects (Raw Data Upload Request Dataset) non-empty

Datasets containing raw data for training.

object

Details for the webhook endpoint to call when a job finishes.

Example
{
  • "datasets": [
    ],
  • "webhook": {}
}

  1. Send PUT Request: Issue a PUT request to the presigned url with the JSON file in the body.

    After initiating the PUT request, the service begins validating and refining the uploaded data. This validation ensures compliance with the required schema. If data for any Dataset is invalid, the job status is updated, and no data is stored. The refinement process assesses existing data for each Dataset ID, replaces duplicates, and stores new records. It's advisable for the client to regularly upload new approved data on a monthly basis.

  2. Check Status: Use GET /status with the Job ID in the header until it returns 200 with status="success", or utilize webhooks.

    If the status returns as INVALID this indicates that validation of sent payload has failed. The same status response will also contain info about type of error that happened and additional details.

Data validation​

After the historical data is successfully uploaded via a presigned URL, the data validation process is automatically triggered. This process ensures the integrity and correctness of the incoming data by applying various checks.

Validation results can be retrieved either through a webhook or by calling GET /status with the Job ID in the header. Continue polling this endpoint until a 200 status code is returned with status="success" or status="invalid" (in case where data sent did not pass validation). Please note that validation may take some time, and the 200 status code will only be returned once validation is complete.

Data invalid response​

If validation has found errors in the uploaded payload, information about errors will be available in message field of the JSON response (either the one got from the webhook or through GET /status endpoint):

Example of the job status for payload with error
{
  "jobId": "5dfcd95abdb84e9d8772cbfr17ag029f",
  "status": "invalid",
  "message": {
    "errors": {
      // Contains information about validation errors for job level
    }
  },
  "datasetsStatus": [
    {
      "datasetId": "example-dataset",
      "status": "invalid",
      "message": {
        "errors": {
          // Contains information about validation errors for dataset level
        }
      }
    }
  ]
}

Error message structure​

When validation finds errors in the payload, they will be returned in the following structure:

{
  "errors": [
    {
      "message": "Transaction limit exceeded for payslip payslip_1 in month 2021-01",
      "details": "Total number of transactions for payslip payslip_1 in month 2021-01 is 150, which exceeds the transaction limit of 100.",
      "error_type": "TOO_MANY_TRANSACTIONS",
      "incorrect_value": 150,
      "rule_violated": {
        "LESS_THAN_EQUAL": 100
      },
      "location": ["datasets", 0, "payslips", 0]
    }
  ]
}
  • message - Short description of error
  • details - Detailed description of error
  • error_type - Enum describing type of error. See Error type
  • incorrect_value - Payload value that is responsible for breaking the rule
  • rule_violated - Rule that was violated and value associated with that rule. See Validation rule
  • location - Where in payload structure this error was detected. See Error location

Error types​

Error type is an enum describing the error that occurred and can be used to programmatically handle error on Integrators side.

List of possible error types that can be returned

ANY_NON_ZERO_NOT_PRESENT - None of the specified fields are defined and non-zero. This error is triggered when a rule specifies that at least one of the listed fields must be defined and non-zero, but none of them are.

Specific rule, not defined through YAML api specification.

Payload example:

{
  "webhook": {
    "webhookUrl": "https://example.com/1b1bs1b1b1b1b",
    "webhookApiKey": "1234567890"
  },
  "datasets": [
    {
      "id": "dataset_1",
      "payslips": [
        {
          "id": "payslip_1",
          "date": "2021-01-01",
          "employeeId": "12312",
          "employeeGroups": ["s123"],
          "transactions": [
            {
              "id": "transaction_1",
              "unit": "EUR",
              "subType": "type",
              "type": "salary",
              "fromDate": "2021-01-01",
              "toDate": "2021-01-31"
            }
          ]
        }
      ]
    }
  ]
}

JSON response example:

{
  "message": "At least one of fields (amount, quantity, rate) must be present and non-zero",
  "details": "Transaction with id = transaction_1 does not have at least one of the fields defined and non-zero: amount, quantity, rate. Please define at least one of those fields and try again.",
  "error_type": "ANY_NON_ZERO_NOT_PRESENT",
  "incorrect_value": null,
  "rule_violated": {
    "ANY_NON_ZERO_REQUIRED": "(amount, quantity, rate)"
  },
  "location": ["datasets", 0, "payslips", 0, "transactions", 0]
}

DATASET_ID_NOT_UNIQUE - The dataset ID is not unique. Each dataset should have a unique ID.

Specific rule, not defined through YAML api specification.

Payload example:

{
 "webhook": {
   "webhookUrl": "https://example.com/1b1bs1b1b1b1b",
   "webhookApiKey": "1234567890"
 },
 "datasets": [
   {
     "id": "dataset_1",
     "payslips": [
       ...
     ]
   }, {
     "id": "dataset_1",
     "payslips": [
       ...
     ]
   }, {
     "id": "dataset_1",
     "payslips": [
       ...
     ]
   }
 ]
}

JSON response example:

{
  "message": "Duplicated dataset ids",
  "details": "Each dataset should have a unique id. However, there are duplicated dataset ids: ['dataset_1']",
  "error_type": "DATASET_ID_NOT_UNIQUE",
  "incorrect_value": "['dataset_1']",
  "rule_violated": {
    "UNIQUE": "dataset_id"
  },
  "location": null
}

DOESNT_MATCH_REGEX - The input value does not match the required pattern.

Rule that can be defined through YAML api specification.

Minimal API specs example:

pattern_field:
  type: string
  pattern: "^[a-z]+$"

Payload example:

{
  "pattern_field": "123"
}

JSON response example:

{
  "message": "String should match pattern '^[a-z]+$'",
  "details": "Error in pattern_field: String should match pattern '^[a-z]+$'",
  "error_type": "DOESNT_MATCH_REGEX",
  "incorrect_value": "123",
  "rule_violated": {
    "MATCH_REGEX": "^[a-z]+$"
  },
  "location": ["pattern_field"]
}

FIELD_MISSING - A required field is missing from the payload.

Rule that can be defined through YAML api specification.

Payload example:

{
  "webhook": {
    "webhookUrl": "https://example.com/1b1bs1b1b1b1b",
    "webhookApiKey": "1234567890"
  },
  "datasets": [
    {
      "id": "dataset_1",
      "payslips": [
        {
          "id": "payslip_1",
          "date": "2021-01-01",
          "employeeId": "12312",
          "employeeGroups": ["s123"],
          "transactions": [
            {
              "id": "transaction_1",
              "unit": "EUR",
              "subType": "type",
              "type": "salary",
              "toDate": "2021-01-31"
            }
          ]
        }
      ]
    }
  ]
}

JSON response example:

{
  "message": "Field required",
  "details": "Error in datasets -> 0 -> payslips -> 0 -> transactions -> 0 -> fromDate: Field required",
  "error_type": "FIELD_MISSING",
  "incorrect_value": null,
  "rule_violated": null,
  "location": ["datasets", 0, "payslips", 0, "transactions", 0, "fromDate"]
}

INVALID_BOOLEAN_VALUE - The input field should be a boolean but is a string (or another type) that cannot be converted to a boolean value.

Rule that can be defined through YAML api specification.

Minimal API specs example:

flag:
  type: boolean

Payload example:

{
  "flag": "not-a-bool"
}

JSON response example:

{
  "message": "Input should be a valid boolean, unable to interpret input",
  "details": "Error in flag: Input should be a valid boolean, unable to interpret input",
  "error_type": "INVALID_BOOLEAN_VALUE",
  "incorrect_value": "not-a-bool",
  "rule_violated": null,
  "location": ["flag"]
}

INVALID_DATE_VALUE - The input value is a string (or another type) that cannot be parsed into a date.

Rule that can be defined through YAML api specification.

Minimal API specs example:

date_field:
  type: string
  format: date

Payload example:

{
  "date_field": "2021-13-01"
}

JSON response example:

{
  "message": "Input should be a valid date or datetime, month value is outside expected range of 1-12",
  "details": "Error in date_field: Input should be a valid date or datetime, month value is outside expected range of 1-12",
  "error_type": "INVALID_DATE_VALUE",
  "incorrect_value": "2021-13-01",
  "rule_violated": null,
  "location": ["date_field"]
}

INVALID_DATETIME_VALUE - The input value is of a type that cannot be parsed into a datetime, or it's a string that is not in a format that can be parsed into a datetime.

Rule that can be defined through YAML api specification.

Minimal API specs example:

datetime_field:
  type: string
  format: date-time

Payload example:

{
  "datetime_field": "2021-01-01T25:00:00"
}

JSON response example:

{
  "message": "Input should be a valid datetime or date, unexpected extra characters at the end of the input",
  "details": "Error in datetime_field: Input should be a valid datetime or date, unexpected extra characters at the end of the input",
  "error_type": "INVALID_DATETIME_VALUE",
  "incorrect_value": "2021-01-01T25:00:00",
  "rule_violated": null,
  "location": ["datetime_field"]
}

INVALID_DECIMAL_VALUE - The input value is of a type that cannot be parsed into a decimal, or it's a string that is not in a format that can be parsed into a decimal.

Rule that can be defined through YAML api specification.

Minimal API specs example:

decimal_field:
  type: string
  format: decimal

Payload example:

{
  "decimal_field": "not-a-decimal"
}

JSON response example:

{
  "message": "Input should be a valid decimal",
  "details": "Error in decimal_field: Input should be a valid decimal",
  "error_type": "INVALID_DECIMAL_VALUE",
  "incorrect_value": "not-a-decimal",
  "rule_violated": null,
  "location": ["decimal_field"]
}

INVALID_FLOAT_VALUE - The input value is of a type that cannot be parsed into a float, or it's a string that is not in a format that can be parsed into a float.

Rule that can be defined through YAML api specification.

Minimal API specs example:

float_field:
  type: number
  format: float

Payload example:

{
  "float_field": "not-a-float"
}

JSON response example:

{
  "message": "Input should be a valid number, unable to parse string as a number",
  "details": "Error in float_field: Input should be a valid number, unable to parse string as a number",
  "error_type": "INVALID_FLOAT_VALUE",
  "incorrect_value": "not-a-float",
  "rule_violated": null,
  "location": ["float_field"]
}

INVALID_INTEGER_VALUE - The input value is of a type that cannot be parsed into an integer, or it's a string that is not in a format that can be parsed into an integer.

Rule that can be defined through YAML api specification.

Minimal API specs example:

integer_field:
  type: integer

Payload example:

{
  "integer_field": 1.5
}

JSON response example:

{
  "message": "Input should be a valid integer, got a number with a fractional part",
  "details": "Error in integer_field: Input should be a valid integer, got a number with a fractional part",
  "error_type": "INVALID_INTEGER_VALUE",
  "incorrect_value": 1.5,
  "rule_violated": null,
  "location": ["integer_field"]
}

INVALID_ITERABLE_VALUE - The input value is not a valid iterable object.

Rule that can be defined through YAML api specification.

Minimal API specs example:

iterable_field:
  type: array

Payload example:

{
  "iterable_field": "not-iterable"
}

JSON response example:

{
  "message": "Input should be a valid list",
  "details": "Error in iterable_field: Input should be a valid list",
  "error_type": "INVALID_LIST_VALUE",
  "incorrect_value": "not-iterable",
  "rule_violated": null,
  "location": ["iterable_field"]
}

INVALID_LIST_VALUE - The input value is not valid as a list.

Rule that can be defined through YAML api specification.

Minimal API specs example:

list_field:
  type: array

Payload example:

{
  "list_field": "not-a-list"
}

JSON response example:

{
  "message": "Input should be a valid list",
  "details": "Error in list_field: Input should be a valid list",
  "error_type": "INVALID_LIST_VALUE",
  "incorrect_value": "not-a-list",
  "rule_violated": null,
  "location": ["list_field"]
}

INVALID_STRING_VALUE - The input value is not valid for a string field.

Rule that can be defined through YAML api specification.

Minimal API specs example:

string_field:
  type: string

Payload example:

{
  "string_field": 123
}

JSON response example:

{
  "message": "Input should be a valid string",
  "details": "Error in string_field: Input should be a valid string",
  "error_type": "INVALID_STRING_VALUE",
  "incorrect_value": 123,
  "rule_violated": null,
  "location": ["string_field"]
}

INVALID_TIME_VALUE - The input value is of a type that cannot be parsed into a time, or it's a string that is not in a format that can be parsed into a time.

Rule that can be defined through YAML api specification.

Minimal API specs example:

time_field:
  type: string
  format: time

Payload example:

{
  "time_field": "not-a-time"
}

JSON response example:

{
  "message": "Input should be in a valid time format, invalid character in hour",
  "details": "Error in time_field: Input should be in a valid time format, invalid character in hour",
  "error_type": "INVALID_TIME_VALUE",
  "incorrect_value": "not-a-time",
  "rule_violated": null,
  "location": ["time_field"]
}

INVALID_UUID_VALUE - The input value is not a valid UUID instance.

Rule that can be defined through YAML api specification.

Minimal API specs example:

uuid_field:
  type: string
  format: uuid

Payload example:

{
  "uuid_field": "not-a-uuid"
}

JSON response example:

{
  "message": "Input should be a valid UUID, invalid character: expected an optional prefix of `urn:uuid:` followed by [0-9a-fA-F-], found `n` at 1",
  "details": "Error in uuid_field: Input should be a valid UUID, invalid character: expected an optional prefix of `urn:uuid:` followed by [0-9a-fA-F-], found `n` at 1",
  "error_type": "INVALID_UUID_VALUE",
  "incorrect_value": "not-a-uuid",
  "rule_violated": null,
  "location": ["uuid_field"]
}

NOT_A_MULTIPLE_OF - The input value is not a multiple of the field's 'multiple_of' constraint.

Rule that can be defined through YAML api specification.

Minimal API specs example:

multiple_field:
  type: number
  multipleOf: 2

Payload example:

{
  "multiple_field": 5
}

JSON response example:

{
  "message": "Input should be a multiple of 2",
  "details": "Error in multiple_field: Input should be a multiple of 2",
  "error_type": "NOT_A_MULTIPLE_OF",
  "incorrect_value": 5,
  "rule_violated": {
    "MULTIPLE_OF": 2.0
  },
  "location": ["multiple_field"]
}

PAYSLIP_ID_NOT_UNIQUE - The payslip ID is not unique. Each payslip should have a unique ID.

Specific rule, not defined through YAML api specification.

Payload example:

{
 "webhook": {
   "webhookUrl": "https://example.com/1b1bs1b1b1b1b",
   "webhookApiKey": "1234567890"
 },
 "datasets": [
   {
     "id": "dataset_1",
     "payslips": [
       {
         "id": "12312",
         "date": "2021-01-01",
         "employeeId": "12312",
         "transactions": [
           ...
         ]
       }, {
         "id": "12312",
         "date": "2021-01-01",
         "employeeId": "12312",
         "transactions": [
           ...
         ]
       }
     ]
   }
 ]
}

JSON response example:

{
  "message": "Duplicated payslip ids",
  "details": "Each payslip should have unique id. However, there are duplicated payslip ids: ['12312']",
  "error_type": "PAYSLIP_ID_NOT_UNIQUE",
  "incorrect_value": "['12312']",
  "rule_violated": {
    "UNIQUE": "payslip_id"
  },
  "location": null
}

STRING_TOO_LONG - The input value is a string whose length exceeds the field's max_length constraint.

Rule that can be defined through YAML api specification.

Minimal API specs example:

string_field:
  type: string
  maxLength: 5

Payload example:

{
  "string_field": "123456"
}

JSON response example:

{
  "message": "String should have at most 5 characters",
  "details": "Error in string_field: String should have at most 5 characters",
  "error_type": "STRING_TOO_LONG",
  "incorrect_value": "123456",
  "rule_violated": {
    "MAX_LENGTH": 5
  },
  "location": ["string_field"]
}

STRING_TOO_SHORT - The input value is a string whose length is less than the field's min_length constraint.

Rule that can be defined through YAML api specification.

Minimal API specs example:

string_field:
  type: string
  minLength: 10

Payload example:

{
  "string_field": "123456"
}

JSON response example:

{
  "message": "String should have at least 10 characters",
  "details": "Error in string_field: String should have at least 10 characters",
  "error_type": "STRING_TOO_SHORT",
  "incorrect_value": "123456",
  "rule_violated": {
    "MIN_LENGTH": 10
  },
  "location": ["string_field"]
}

TOO_LONG - The input value (e.g., a list) exceeds the field's max_length constraint.

Rule that can be defined through YAML api specification.

Minimal API specs example:

list_field:
  type: array
  maxItems: 2

Payload example:

{
  "list_field": [1, 2, 3]
}

JSON response example:

{
  "message": "List should have at most 2 items after validation, not 3",
  "details": "Error in list_field: List should have at most 2 items after validation, not 3",
  "error_type": "TOO_LONG",
  "incorrect_value": [1, 2, 3],
  "rule_violated": {
    "MAX_LENGTH": 2
  },
  "location": ["list_field"]
}

TOO_MANY_TRANSACTIONS - There are too many transactions within one month for a specific payslip.

Specific rule, not defined through YAML api specification.

Payload example:

{
 "webhook": {
   "webhookUrl": "https://example.com/1b1bs1b1b1b1b",
   "webhookApiKey": "1234567890"
 },
 "datasets": [
   {
     "id": "dataset_1",
     "payslips": [
       {
         "id": "payslip_1",
         "date": "2021-01-01",
         "employeeId": "12312",
         "transactions": [
           {
             "id": "transaction_1",
             "amount": 1000,
             "unit": "EUR",
             "subType": "type",
             "type": "salary",
             "fromDate": "2021-01-01",
             "toDate": "2021-01-31"
           }, {
             "id": "transaction_2",
             "amount": 1500,
             "unit": "EUR",
             "subType": "type",
             "type": "salary",
             "fromDate": "2021-01-01",
             "toDate": "2021-01-31"
           }, {
             "id": "transaction_3",
             "amount": 1000,
             "unit": "EUR",
             "subType": "type",
             "type": "salary",
             "fromDate": "2021-01-01",
             "toDate": "2021-01-31"
           },
            ...
            ...
           }, {
             "id": "transaction_150",
             "amount": 1000,
             "unit": "EUR",
             "subType": "type",
             "type": "salary",
             "fromDate": "2021-01-01",
             "toDate": "2021-01-31"
           }
         ]
       }
     ]
   }
 ]
}

JSON response example:

{
  "message": "Transaction limit exceeded for payslip payslip_1 in month 2021-01",
  "details": "Total number of transactions for payslip payslip_1 in month 2021-01 is 150, which exceeds the transaction limit of 100.",
  "error_type": "TOO_MANY_TRANSACTIONS",
  "incorrect_value": 150,
  "rule_violated": {
    "LESS_THAN_EQUAL": 100
  },
  "location": ["datasets", 0, "payslips", 0]
}

TOO_SHORT - The input value (e.g., a list) is shorter than the field's min_length constraint.

Rule that can be defined through YAML api specification.

Minimal API specs example:

list_field:
  type: array
  minItems: 5

Payload example:

{
  "list_field": [1, 2, 3]
}

JSON response example:

{
  "message": "List should have at least 5 items after validation, not 3",
  "details": "Error in list_field: List should have at least 5 items after validation, not 3",
  "error_type": "TOO_SHORT",
  "incorrect_value": [1, 2, 3],
  "rule_violated": {
    "MIN_LENGTH": 5
  },
  "location": ["list_field"]
}

TRANSACTION_ID_NOT_UNIQUE - The transaction ID is not unique. Each transaction should have a unique ID.

Specific rule, not defined through YAML api specification.

Payload example:

{
  "webhook": {
    "webhookUrl": "https://example.com/1b1bs1b1b1b1b",
    "webhookApiKey": "1234567890"
  },
  "datasets": [
    {
      "id": "dataset_1",
      "payslips": [
        {
          "id": "12312",
          "date": "2021-01-01",
          "employeeId": "12312",
          "transactions": [
            {
              "id": "transaction_1",
              "amount": 1000,
              "unit": "EUR",
              "subType": "type",
              "type": "salary",
              "fromDate": "2021-01-01",
              "toDate": "2021-01-31"
            },
            {
              "id": "transaction_1",
              "amount": 1500,
              "unit": "EUR",
              "subType": "type",
              "type": "salary",
              "fromDate": "2021-01-01",
              "toDate": "2021-01-31"
            }
          ]
        }
      ]
    }
  ]
}

JSON response example:

{
  "message": "Duplicated transaction ids",
  "details": "Each transaction should have unique id. However, there are duplicated transaction ids: ['transaction_1']",
  "error_type": "TRANSACTION_ID_NOT_UNIQUE",
  "incorrect_value": "['transaction_1']",
  "rule_violated": {
    "UNIQUE": "transaction_id"
  },
  "location": null
}

UNEXPECTED_FIELD - The incoming payload contains extra fields that are not defined by the API.

Rule that can be defined through YAML api specification.

Minimal API specs example:

required_field:
  type: string

Payload example:

{
  "required_field": "valid",
  "unexpected_field": "not-allowed"
}

JSON response example:

{
  "message": "Extra inputs are not permitted",
  "details": "Error in unexpected_field: Extra inputs are not permitted",
  "error_type": "UNEXPECTED_FIELD",
  "incorrect_value": "not-allowed",
  "rule_violated": null,
  "location": ["unexpected_field"]
}

VALUE_NOT_AN_OBJECT - The input value is expected to be an object but is not.

Rule that can be defined through YAML api specification.

Minimal API specs example:

dict_field:
  type: object

Payload example:

{
  "dict_field": "not-a-dict"
}

JSON response example:

{
  "message": "Input should be a valid dictionary",
  "details": "Error in dict_field: Input should be a valid dictionary",
  "error_type": "VALUE_NOT_AN_OBJECT",
  "incorrect_value": "not-a-dict",
  "rule_violated": null,
  "location": ["dict_field"]
}

VALUE_TOO_HIGH - The field value is too high. This error occurs when a rule specifies that the field should be less than (or equal to) a specific value, but the value exceeds that limit.

Rule that can be defined through YAML api specification.

Minimal API specs example:

amount:
  type: number
  maximum: 5

Payload example:

{
  "amount": 5.5
}

JSON response example:

{
  "message": "Input should be less than 5",
  "details": "Error in amount: Input should be less than 5",
  "error_type": "VALUE_TOO_HIGH",
  "incorrect_value": 5.5,
  "rule_violated": {
    "LESS_THAN_EQUAL": 5
  },
  "location": ["amount"]
}

VALUE_TOO_LOW - The field value is too low. This error occurs when a rule specifies that the field should be greater than (or equal to) a specific value, but the value is below that limit.

Rule that can be defined through YAML api specification.

Minimal API specs example:

amount:
  type: number
  minimum: 5.1

Payload example:

{
  "amount": 5.0
}

JSON response example:

{
  "message": "Input should be greater than 5.1",
  "details": "Error in amount: Input should be greater than 5.1",
  "error_type": "VALUE_TOO_LOW",
  "incorrect_value": 5.0,
  "rule_violated": {
    "GREATER_THAN": 5.1
  },
  "location": ["amount"]
}

Validation rule​

List of possible validation rules that can be returned in error status response
Rule NameDescription
ANY_NON_ZERO_REQUIREDAt least one of the specified fields must be present and non-zero. See ANY_NON_ZERO_NOT_PRESENT.
GREATER_THANThe field value must be greater than the specified value. See VALUE_TOO_LOW.
GREATER_THAN_EQUALThe field value must be greater than or equal to the specified value.
LESS_THANThe field value must be less than the specified value.
LESS_THAN_EQUALThe field value must be less than or equal to the specified value. See VALUE_TOO_HIGH and TOO_MANY_TRANSACTIONS.
MATCH_REGEXThe field value must match the specified regular expression pattern. See DOESNT_MATCH_REGEX.
MAX_LENGTHThe length of the string or list must be less than or equal to the specified maximum length. See TOO_LONG and STRING_TOO_LONG.
MIN_LENGTHThe length of the string or list must be greater than or equal to the specified minimum length. See TOO_SHORT and STRING_TOO_SHORT.
MULTIPLE_OFThe field value must be a multiple of the specified value. See NOT_A_MULTIPLE_OF.
UNIQUEThe field value must be unique across the dataset or a subset of it. See TRANSACTION_ID_NOT_UNIQUE, PAYSLIP_ID_NOT_UNIQUE and DATASET_ID_NOT_UNIQUE.

Error location​

Provides a path within the JSON structure where the error occurred, allowing to pinpoint exactly which part of the input data caused the validation error.

Examples
{
  "location": ["employeeId"]
}

Explanation: The error is located at the employeeId field at the top level of the JSON object.

{
  "location": ["datasets", 0, "payslips", 0, "transactions", 2, "amount"]
}

Explanation: This indicates that the error is in the amount field of the third transaction (index 2) in the first payslip (index 0) within the first dataset (index 0).

{
  "location": ["datasets", 1, "payslips", 3, "employeeGroups", 0]
}

Explanation: The error is in the first element (index 0) of the employeeGroups array within the fourth payslip (index 3) in the second dataset (index 1).