What's changed

OSF is closing to new experiments

OSF is shutting down its projects feature, so DataPipe can no longer create new experiments there. DataPipe will stop writing to OSF after November 16, 2026. An experiment already collecting on OSF keeps collecting until then.

What changes, what happens to data you already collected, and how to move to another provider. Moving off OSF

Three new storage providers

DataPipe can now send data to three more places.

Google Drive. Your own Drive, in a folder DataPipe creates. It is the quickest to connect.

Dataverse. Institutional repositories run by universities and consortia, such as Harvard Dataverse or Borealis. Choose it when your institution runs one and your data should stay under its terms.

Zenodo. An open repository run by CERN. Choose it for a study you plan to publish and cite: publishing a record issues a DOI.

A full comparison, including each provider's limits and what it does with a duplicate filename. Choosing a provider

How to connect one, and what to do when a credential expires. Connecting and reconnecting

Saving data as the experiment runs

An experiment can now send each trial to DataPipe as it happens, instead of only once at the end. In jsPsych, register the @jspsych/extension-pipe extension and it streams by default. Outside jsPsych, the framework-neutral datapipe-client library does the same when your experiment starts a session with it.

When a participant closes the tab or loses their connection partway through, you keep the trials they finished. DataPipe assembles them into a partial file, usually about fifteen minutes after the participant leaves. While a study runs, the experiment's dashboard shows Sessions in progress: how many participants are partway through, and how long each has been going.

An experiment that saves once at the end with the older jsPsychPipe plugin keeps working as it does now.

What to expect, what it means for privacy, and the limits it runs under. Saving as you go

When an upload fails

When your storage provider can't take a submission, DataPipe now keeps a copy and retries: up to five attempts over about 31 hours. The experiment's dashboard lists every file that is waiting or being retried. You can download any of them, or all of them as one ZIP, without waiting for a retry to succeed.

DataPipe sends one email when an experiment's uploads start failing, not one per file, and no more until the problem clears. It keeps a queued file for seven days, or up to fourteen if that email could not be delivered.

The retry schedule, what each status on the panel means, and how to download a queued file. When an upload fails

Psych-DS metadata

With Psych-DS metadata turned on, DataPipe now writes a dataset_description.json, a data table per session, and a sidecar table for any column that held nested values (survey responses, mouse-tracking samples). The tables go in data/. Your original submission is kept, byte for byte, in data/raw/.

Decide before you start collecting. You can change the setting until the first submission arrives. After that it locks for the life of the experiment. To change it later, create a new experiment.

What gets written, where the variable descriptions come from, and why the setting locks. Psych-DS metadata

Finalizing a dataset

When a Zenodo study is done, you can finalize the experiment from its dashboard. DataPipe merges everything into a single archive and permanently stops accepting submissions. Finalizing can't be undone, so do it only when you are certain no more data is coming.

During collection, DataPipe also bundles files into archives by itself when a Zenodo record nears its 100-file limit. Nothing is lost: your sessions are inside the archives.

What finalizing does, which providers support it, and why it can't be undone. Finishing a study

Rejected submissions

Each experiment's dashboard now lists the submissions DataPipe refused, with the reason and the time of each. Before, a refusal left nothing you could see.

Use Clear this list once you have dealt with the entries. Later refusals appear as they happen.

Why a rejected submission can't be recovered, and how to test your validation rules before participants arrive. Rejected data is gone

A new look

The dashboard and the documentation have been redesigned, and DataPipe now uses a dark theme throughout.

More ways to sign in

You can sign in to DataPipe with Google, ORCID, GitHub, or an email address and password, and add more than one to the same account. OSF sign-in is being retired along with the rest of OSF support.

Deleting your account removes every experiment you own and everything DataPipe holds about them. Files already in your storage provider stay where they are.

Sign-in methods, how credentials are stored, and what account deletion removes. Account and security

A contact email for every account

If your account has no contact email address, DataPipe asks for one the next time you sign in, before it shows your experiments. It uses the address for one thing: telling you when uploads for one of your experiments start failing. Your experiments keep collecting whether or not you have signed in.

DataPipe notifies an unconfirmed address too, but it can't know the message arrives. You can change or confirm the address at any time in account settings.

Privacy and data handling

DataPipe now has a privacy page written for IRB protocols and institutional security reviews: what it processes, what it stores, encryption, and where data is processed.

A submission held for retry is encrypted (AES-256-GCM) for as long as DataPipe holds it. Disconnecting Google Drive from your account settings deletes DataPipe's stored token and asks Google to revoke DataPipe's authorization.

A paragraph you can adapt for a protocol, plus retention, access, and what DataPipe does not do with your data. Privacy & information for IRBs

Two small changes can affect code you have already written. The way you send data, and every HTTP status code, are unchanged.

Three error codes were renamed

Three error codes lost their OSF prefix, because every storage provider returns them: OSF_FILE_EXISTS is now FILE_EXISTS, OSF_UPLOAD_ERROR is now UPLOAD_ERROR, and OSF_UPLOAD_EXCEPTION is now UPLOAD_EXCEPTION.

This matters only to code that compares the error field of a response with one of the old names. Code that picks a new filename and retries after OSF_FILE_EXISTS is the usual case. That comparison now fails without an error.

The full table, with what each one means and what status it comes back with. Error codes

The metadataOptions parameter was removed

The data-saving endpoint no longer reads a metadataOptions field in the request body. The field was never documented, and it let any participant's submission set the name, author, or license in your dataset's description. If your code sends it, DataPipe ignores it.

Check this list against your own setup. An item applies only if its first sentence describes you.

• Your code compares the error field with an old name. Change it to the new name, or test for both names until every experiment is updated. See Three error codes were renamed.
• Your code sends metadataOptions. Remove it. See The metadataOptions parameter was removed.
• You have experiments on OSF. If your account settings ask you to re-authorize OSF, do it, so those experiments can keep saving. For a new study, connect Google Drive, Dataverse, or Zenodo. See OSF is closing to new experiments.
• OSF is your only way to sign in. Link another sign-in method in your account settings. Without one, you can lose access to the account that owns your experiments. See More ways to sign in.
• DataPipe asks you for a contact email. Enter an address, then confirm it from the email DataPipe sends. See A contact email for every account.

If something on this page doesn't match what you see, or you hit a problem after the update, open an issue on GitHub or write to the address on the contact page.