Validation and session limits

Validation checks each submission before DataPipe sends it to your storage provider, and rejects anything that does not 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. That is the usual reason a first test submission comes back rejected — data that is not jsPsych output 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 is well-formed in either of the formats you allow. A rejection is a 400 carrying INVALID_DATA: “The data are not valid according to the validation parameters set for this experiment.” DataPipe does not say which check failed, so test 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 does not satisfy the requirement, 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 of its own: every row must have the same number of cells as the first row. A ragged file is rejected even when you have listed no required fields at all — an unquoted comma inside a response is the usual culprit.

On the dashboard, type a name and press Enter or comma to add it, or paste a comma-separated list in one go. 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 exists to block malicious submissions, not to catch mistakes in legitimate data.

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

Unchecking both Allow JSON and Allow CSV while validation is on stops your experiment collecting data entirely. There is no format left that a submission could be valid in, so every one of them is rejected with INVALID_DATA and destroyed.

Nothing in the dashboard prevents this combination, and nothing about it looks broken from the outside — the experiment still reports that it is accepting data. If submissions are being rejected and you cannot see why, check these two boxes first.

A session limit stops an experiment from overrunning 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 has not 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 is 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 little 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 as an exact quota. If exactly n complete datasets matter, check the count on your dashboard before you close recruitment.

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

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