Validation and session limits

Validation checks each submission before DataPipe sends it to your storage provider and rejects anything that doesn't match the rules you set. You can require a file to be well-formed JSON or CSV, and you can list columns or fields it must contain.

Validation is on for every new experiment, with JSON and CSV both allowed and one required field: trial_type. This is the most common reason a first test submission gets rejected. Data that didn't come from jsPsych has no trial_type column, so it fails the check until you edit or clear the required fields on the dashboard.

A submission passes if it's well-formed in either of the formats you allow. A rejection comes back as a 400 with INVALID_DATA: “The data are not valid according to the validation parameters set for this experiment.” DataPipe doesn't say which check failed, so run a real session yourself before you recruit.

Required fields are matched against the top level of your data only. A field nested inside another object doesn't count, however deep it is.

• JSON, as an array: the usual shape for jsPsych output. DataPipe collects the keys from every object in the array and requires each of your fields to appear in at least one of them. A field that only one trial carries still counts as present.
• JSON, as a single object: the required fields must be keys of that object.
• CSV: required fields are checked against the header row only, so a column that exists but is empty in every row still passes. CSV has one extra rule: every row must have the same number of cells as the first row. A ragged file is rejected even if you haven't listed any required fields. The usual culprit is an unquoted comma inside a response.

On the dashboard, type a name and press Enter or comma to add it, or paste a comma-separated list all at once. Each name becomes a chip showing exactly the text that will be matched, so a stray space or a pasted quote is visible before it costs you a session. Remove every chip and DataPipe checks only that the file is well-formed.

The check runs before DataPipe takes its own copy of the submission, which is why nothing survives it. Validation is there to block bad submissions, not to catch mistakes in legitimate data.

So set your rules deliberately, and test them once, end to end, with your real experiment before the first participant arrives.

With validation on and neither Allow JSON nor Allow CSV checked, an experiment stops collecting data entirely. There's no format left for a submission to be valid in, so every one of them is rejected with INVALID_DATA and destroyed.

The dashboard no longer lets you get there: it keeps the last format checked and tells you why. An experiment that was already set up this way before that change is still in that state, though, and nothing looks broken from the outside — it still reports that it's accepting data. If submissions are being rejected and you can't see why, check these two boxes first.

A session limit keeps an experiment from overshooting its recruitment target. Once the number of accepted submissions reaches the limit, every further submission is rejected with SESSION_LIMIT_REACHED. You can raise the limit at any time and collection resumes immediately. The field starts at 1, so set it when you turn the switch on.

Four details decide whether the cap does what you expect:

• A queued upload still counts. If DataPipe accepted the data but hasn't delivered it to your provider yet, it has already used one of your sessions. The count tracks what DataPipe accepted, not what has landed.
• Only data submissions are counted. Condition requests and base64 file uploads are neither counted nor blocked by the cap, so an experiment at its limit can still receive media files.
• A burst can overshoot slightly. The count is read when a submission arrives and written when it's accepted. Several participants who submit in the same instant can each pass the check before any of them is counted, so a cap of 50 can end up with a few more than 50 sessions.
• A rejected submission does not count. Data that fails validation, arrives with a duplicate filename, or hits a switched-off experiment never reaches the counter.

Because of the last two points, treat the limit as a guard rail rather than an exact quota. If you need exactly n complete datasets, check the count on your dashboard before you close recruitment.

Anyone who reads your experiment's code can see its experiment ID, and that ID is all it takes to submit. That's the trade DataPipe makes so participants don't need accounts and you don't need a server. Validation, the session limit, and turning off data collection when a study ends are the three controls that keep it in check.

What reaches DataPipe, how long it's kept, and who can read it. What DataPipe stores