Connecting and reconnecting

Google Drive and Zenodo connect with one click. You approve DataPipe on their site, and from then on DataPipe manages the tokens for you, including refreshing them before they expire.

Dataverse works differently. You create an API token on your institution's installation and paste it into DataPipe. That gives you direct control, but nothing can renew the token for you. When it expires, data stops arriving until you create a new one and reconnect. Either way, tokens are stored encrypted.

You connect, reconnect, and disconnect every provider from the Storage Providers section of your account settings. A green Connected label tells you it worked.

Click Connect and Google's own sign-in page opens so you can authorize DataPipe. Then you come straight back.

DataPipe asks Google for a single permission, drive.file, which covers only the files and folders DataPipe itself creates. It can't open, list, or change anything else in your Drive, including files you later drag into the experiment folder by hand.

Click Connect and Zenodo opens so you can authorize DataPipe. Then you come straight back. DataPipe asks for permission to upload files to your depositions and to edit them. It never publishes a record, so nothing becomes public until you say so.

Which Zenodo you connect to depends on which DataPipe site you're using, not on the connection itself. The live site connects to zenodo.org, and the test site connects to the Zenodo sandbox.

For Dataverse, Connect opens a short form instead of sending you to another site. It asks for the full address of your institution's installation (for example, https://dataverse.harvard.edu) and an API token, which you create under the API Token tab of your Dataverse account.

The address must be the plain https address of a named installation. DataPipe rejects anything else: no http, no username or password in the address, no non-standard port, no IP address, and no internal or single-word hostname. The reason is that DataPipe's server makes authenticated requests to whatever address you enter, so it has to be strict.

DataPipe checks the token against your installation before saving it. An expired or mistyped token is refused right when you paste it, not at the first participant's submission.

When the credential for an experiment's provider stops working, that experiment stops saving data. Submissions come back with PROVIDER_TOKEN_EXPIRED ("The API token for this experiment's storage provider has expired. A new token must be created on that provider and reconnected to DataPipe"), or with PROVIDER_NOT_CONNECTED if the connection was removed entirely. Data that arrives during a brief provider outage is queued and retried, but a retry can't fix an expired credential.

Google Drive and Zenodo renew themselves.

Google Drive access tokens are short-lived. DataPipe renews one on the next submission that needs it, and a sweep every Sunday at 02:00 UTC renews any that are about to lapse. Zenodo tokens last about two months, and DataPipe renews one a few minutes before it expires, on the next submission that needs it. Neither needs anything from you.

Dataverse can't.

A Dataverse API token has no way to renew itself. It eventually expires, commonly a year after you create it, and only you can replace it. Dataverse doesn't show the expiry date anywhere in its own interface, so DataPipe reads it from your installation each time you create an experiment on Dataverse and shows the date on that form when the token expires within the next 60 days. The date comes from a message your installation writes in its own local time, so treat it as accurate to about a day and reconnect with room to spare.

A provider whose credential has expired still shows as connected. The connection exists, it just no longer works. So replacing it takes two steps in the Storage Providers section of your account settings: disconnect the provider, then connect it again.

For Google Drive and Zenodo, connecting again means approving DataPipe on their site once more. For Dataverse, create a fresh API token on your installation first, then connect with that token and the same server address.

Your experiments aren't affected. Each one keeps writing to the Drive folder, Dataverse dataset, or Zenodo deposition it already has. Submissions that failed while the credential was expired are retried automatically, as long as they haven't used up their five attempts, which takes about 31 hours from when they were queued.

If a one-click authorization never brings you back (say you left the tab sitting, or opened the link twice), start again from the account page. The link DataPipe hands to the provider works once and expires ten minutes after it's created.

What happens to submissions that arrived while the connection was broken, and how long you have to fix it. When an upload fails

Disconnecting stops new data from reaching that provider. It never removes data already stored there.

The only thing it deletes is that provider's stored credential. Your other connections, your experiments, and everything already in your storage stay exactly as they are, and you can reconnect at any time. Before you disconnect, DataPipe tells you how many of your experiments send data to that provider, including ones that are currently paused.

A legacy OSF connection is the one exception. It isn't managed here and can't be disconnected from this screen.

Where credentials are stored, and what deleting your account removes. Account and security