Validation errors

When uploading or overriding data, it is essential that the data conform to the platform's schema. The platform performs validation on your data to ensure it meets the required format, types, and constraints. Due to the complexity of data compliance with our schemas, it is common to encounter validation errors during upload.

These validation errors are useful for identifying which rows or columns of your data do not conform to expectations, enabling you to make the necessary corrections and resubmit your data.

Interpreting Validation Errors

If the status of the override request is error, the validationErrors field provides detailed information about what went wrong during the validation process.

The structure of this field is designed to help you quickly identify and fix issues in your data file. Each error message is crafted to be human-readable, giving clear insights into what failed and why, making debugging much more straightforward, even for those unfamiliar with the internal schema logic.

Please note that while these messages aim to be as understandable and informative as possible, they may evolve over time as the validation framework is improved or extended. It’s a good idea to treat the exact wording of error messages as subject to change.

Let's look at an example of an error response:

{
    "id": "11111111-1111-1111-1111-11111111",
    "collectionId": "11111111-1111-1111-1111-11111111",
    "dataType": "deals",
    "separator": ",",
    "dumpDatetime": "2025-08-07T08:29:39.097529Z",
    "status": "error",
    "message": "Validation failed",
    "validationErrors": [
        {
        "SCHEMA": {
            "SERIES_CONTAINS_NULLS": [
                {
                    "schema": "LeadScoringDealsSchema",
                    "column": "id",
                    "check": "not_nullable",
                    "error": "non-nullable series 'id' contains null values:1    NaNName: id, dtype: object"
                }
            ]
        },
        "DATA": {
            "DATAFRAME_CHECK": [
                {
                    "schema": "LeadScoringDealsSchema",
                    "column": "status",
                    "check": "isin(['closed_won', 'closed_lost', 'open'])",
                    "error": "Column 'status' failed element-wise validator number 0: isin(['closed_won', 'closed_lost', 'open']) failure cases: Unknown Status"
                },
                {
                    "schema": "LeadScoringDealsSchema",
                    "column": "accountId",
                    "check": "str_matches('re.compile('^d+$')')",
                    "error": "Column 'accountId' failed element-wise validator number 0: str_matches('re.compile('^d+$')') failure cases: bz89sd"
                },
                {
                    "schema": "LeadScoringDealsSchema",
                    "column": "companyType",
                    "check": "isin(['public', 'private', 'public_administration'])",
                    "error": "Column 'companyType' failed element-wise validator number 0: isin(['public', 'private', 'public_administration']) failure cases: Unknown"
                },
                {
                    "schema": "LeadScoringDealsSchema",
                    "column": "contactEmailDomainType",
                    "check": "isin(['free_provider', 'company'])",
                    "error": "Column 'contactEmailDomainType' failed element-wise validator number 0: isin(['free_provider', 'company']) failure cases: no Provider"
                },
                {
                    "schema": "LeadScoringDealsSchema",
                    "column": "companyIsCustomer",
                    "check": "is_boolean_string",
                    "error": "Column 'companyIsCustomer' failed element-wise validator number 0: <Check is_boolean_string> failure cases: No"
                }
            ]
        }
    }
    ]
}

Here's a breakdown of the validationErrors structure:

• validationErrors: This is a list containing the validation error objects.
• DATA: This key indicates the validation errors are related to checks performed on the data (e.g., format, type, content).
• DATAFRAME_CHECK: A specific subcategory of DATA errors, typically involving element-wise or row-wise custom checks.
• SCHEMA: This key indicates that the error is related to schema-level validation failures, such as nullability or type checks.
• SERIES_CONTAINS_NULLS: This is a specific type of schema error. In this case, it means a column that shouldn't contain null values does.
• Inside each list (e.g., DATAFRAME_CHECK, SERIES_CONTAINS_NULLS), you'll find one or more objects, each detailing a specific instance of the error:
  • schema: The name of the data schema used for validation (e.g., ContactsDataModel).
  • column: The column in your CSV file that caused the error (e.g., Email).
  • check: The specific validation rule or function that failed.
  • error: A detailed message explaining the problem, often including sample failure cases.

By examining this structure, you can pinpoint the exact column and issue in your data, correct it, and resubmit the override request. In this specific case for example the Email column in the row with index 0 contains a null value, which violates the not_nullable constraint of the data model.

Summary of Validation Errors in the Example

The table below summarizes all the validation errors included in the example response above:

Column	Check Type	Failing Check	Invalid Example	Expected Format/Values
id	SCHEMA	not_nullable	NaN	Non-null unique int identifiers
status	DATA	isin(['closed_won', 'closed_lost', 'open'])	Unknown Status	'closed_won', 'closed_lost', 'open'
accountId	DATA	str_matches('^d+$')	bz89sd	Numeric-only strings (e.g., '123456')
companyType	DATA	isin(['public', 'private', 'public_administration'])	Unknown	'public', 'private', 'public_administration'
contactEmailDomainType	DATA	isin(['free_provider', 'company'])	no Provider	'free_provider', 'company'
companyIsCustomer	DATA	is_boolean_string	No	"true" or "false"