CSV & JSONL Data Validator

Validates bounded inline CSV and JSONL batches against an explicit typed field contract and emits stable batch, finding, and error evidence. It is built for data-ingestion teams, analytics engineers, CI and supplier-data operations. The main result is structured, deterministic evidence that can be consumed from the default dataset or an Apify automation.

When to use this Actor

• Validate a CSV delivery before loading it into a warehouse.
• Check JSONL event exports for types, required values, and declared uniqueness.
• Produce stable finding fingerprints for scheduled data-contract regression evidence.

How it works

• Parse each bounded inline CSV or JSONL batch under the declared format.
• Apply the versioned field contract for required fields, types, ranges, allowed values, additional fields, and uniqueness.
• Persist batch summaries, deterministic findings, and complete REPORTS output before charging one completed-batch event.

The Actor validates only the declared product contract. It does not infer facts outside the supplied data or claim outcomes that the source material cannot prove.

Quick start

1. Open the Actor's Input tab or create a Task from one of the public examples.
2. Paste or adapt this bounded example.
3. Click Start and inspect the default dataset plus the output links shown on the run page.

{
  "batches": [
    {
      "id": "orders-2026-09",
      "format": "csv",
      "content": "order_id,amount,currency\nA-1001,42.50,EUR\nA-1002,18.00,EUR"
    }
  ],
  "contract": {
    "version": "orders-v1",
    "allowAdditionalFields": false,
    "fields": [
      {
        "name": "order_id",
        "type": "string",
        "required": true,
        "unique": true
      },
      {
        "name": "amount",
        "type": "number",
        "required": true,
        "min": 0
      },
      {
        "name": "currency",
        "type": "string",
        "required": true,
        "allowedValues": [
          "EUR",
          "USD"
        ]
      }
    ]
  },
  "maxBatchBytes": 1000000,
  "maxRowsPerBatch": 10000,
  "maxFindingsPerBatch": 1000
}

Expected result: a PASSED batch record with stable contract/input hashes and no finding rows.

Input

The quick-start example is intentionally small. These are the material controls; the Input tab remains authoritative for the complete current schema.

Field	Purpose and format	Default	Important bounds or interaction
batches	Independent inline CSV or JSONL payloads with stable IDs; each batch is validated and reported separately.	No implicit default	minimum items 1; maximum items 100
contract	Typed field rules for required values, uniqueness, ranges, and additional-field handling that every batch is evaluated against.	No implicit default	See the Input tab for the current schema bound.
maxBatchBytes	Maximum UTF-8 payload size accepted for each batch before parsing starts.	1000000	minimum 128; maximum 5000000
maxRowsPerBatch	Maximum parsed record count per batch; exceeding it produces bounded non-billable failure evidence.	10000	minimum 1; maximum 100000
maxFindingsPerBatch	Caps detailed findings retained per batch while summary counts still describe the complete evaluation.	1000	minimum 1; maximum 10000

Unknown top-level fields and invalid field combinations fail validation rather than being guessed.

Output

The default dataset contains typed records. The run's Output tab links the dataset and any key-value-store reports declared by the current output schema.

Field	Meaning
recordType	Identifies batch, finding, or error evidence.
batchId	Current dataset field.
format	Current dataset field.
status	Current dataset field.
rowCount	Current dataset field.
fieldCount	Current dataset field.
findingCount	Current dataset field.
findingsTruncated	Current dataset field.
contractVersion	Current dataset field.
contractHash	Hash of the effective declared contract.
inputHash	Current dataset field.
findingCode	Current dataset field.
severity	Current dataset field.
rowNumber	Current dataset field.
field	Current dataset field.
message	Current dataset field.
fingerprint	Stable finding identity for regression and deduplication.
errorCode	Current dataset field.
errorMessage	Current dataset field.
engineVersion	Current dataset field.

Representative current-schema dataset item:

{
  "recordType": "batch",
  "batchId": "orders-2026-09",
  "format": "csv",
  "status": "PASSED",
  "rowCount": 2,
  "fieldCount": 3,
  "findingCount": 0,
  "findingsTruncated": false,
  "contractVersion": "orders-v1",
  "contractHash": "example-contract-hash",
  "inputHash": "example-input-hash",
  "engineVersion": "1.0.0"
}

A structurally valid empty batch follows the contract's required-field and row semantics; it is never silently populated or inferred.

Pricing and billing

This Actor uses PAY_PER_EVENT; platform usage is included in event prices. A charge is eligible only after the billable unit described below is durably completed. Validation failures and the non-billable failure classes in the product contract do not emit the custom completion event. Higher Store tiers use the complete tier matrix below; Platinum and Diamond match Gold under the current policy. The Apify Pricing tab is authoritative if a later approved pricing change takes effect.

Event	What triggers it	FREE	BRONZE	SILVER	GOLD	PLATINUM	DIAMOND
batch-contract-evaluated	One readable CSV or JSONL batch evaluated to a durable pass/fail contract report.	$0.03000000	$0.02850000	$0.02700000	$0.02550000	$0.02550000	$0.02550000
apify-actor-start	Platform-managed Actor start event.	$0.00005000	$0.00005000	$0.00005000	$0.00005000	$0.00005000	$0.00005000

The Actor does not have Task-specific prices: public Tasks use this same live Actor pricing. Third-party costs are not implied; see the data and security section for external services actually contacted.

Limits and bounds

• Input is inline CSV or JSONL only and must remain within the current per-batch byte, row, and finding bounds.
• The contract is explicit; the Actor does not infer a schema or coerce undeclared formats.
• Displayed findings may be capped, but findingsTruncated and findingCount preserve that fact.

These are product-facing limits, not targets. Use smaller inputs when you need faster feedback or simpler evidence.

Failure and edge-case behavior

• Invalid top-level input or bounds fail closed before processing and before the custom event.
• Malformed rows and contract violations become stable error/finding records rather than being silently corrected.
• A valid batch that violates its contract is still a completed evaluation with truthful FAILED status.

Operationally:

• Version the contract whenever its semantics change.
• Use contractHash, inputHash, and fingerprint to reconcile repeated processing.

Use with Tasks and automation

Public Tasks provide reusable saved inputs for distinct supported workflows. Start with the closest Example Task, review its visible fields and scope caveat, then save your own Task for schedules or repeated runs. Do not treat an Example Task as evidence that unsupported behavior exists.

• Validate a CSV order export contract: Check a safe inline order export for required identifiers, numeric amounts, currency values, uniqueness, and unexpected columns.
• Validate a JSONL event export: Validate newline-delimited event records against a typed field contract before ingestion.
• Find duplicate identifiers in CSV: Find duplicate business identifiers in a CSV export before import.

Integration and API usage

Every saved Task can be started manually, through the Apify API, or from an Apify schedule. Run-completion webhooks can notify a downstream system after output is durable. Actor-to-Actor calls should consume the typed dataset/output links instead of scraping the Store page.

• Run a saved Task as a pre-ingestion CI or scheduled delivery gate.
• Route batch status and findingCode into quarantine, alerts, or data-quality dashboards.

No third-party integration is claimed unless it is named above and supported by the current product contract.

Data, privacy, and security

• Submitted content and evidence remain in Apify run storage under account retention settings.
• No external service is contacted and no credentials are required.

Set Apify storage retention and access according to the sensitivity of your inputs and outputs. This documentation does not create legal, privacy, compliance, or security certification.

Support and known limitations

• The Actor does not fetch remote files, infer business meaning, or certify downstream fitness.
• CSV dialect and JSONL values must fit the documented bounded parser contract.

For support, use the Actor Issues page. Include the run ID, a minimal reproducible input with sensitive values removed, the failing record or error code, and what you expected. Do not post credentials, private source files, customer data, or full confidential payloads.