Connecting and reconnecting

Google Drive and Zenodo use a one-click authorization: you approve DataPipe on their site, and DataPipe then manages the resulting tokens for you, including refreshing them before they expire.

Dataverse uses an API token that you create on your institution's installation and paste into DataPipe. That gives you direct control, but nothing can renew it for you: when the token expires, data stops arriving until you create a new one and reconnect. Tokens are stored encrypted either way.

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

Clicking Connect hands you to Google's own sign-in page to authorize DataPipe, then brings you straight back.

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

Clicking Connect hands you to Zenodo to authorize DataPipe, then brings you 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 installation you are connected to is fixed by this DataPipe deployment, not chosen per connection — the live site connects to zenodo.org, and the test site connects to the Zenodo sandbox.

For Dataverse, clicking Connect opens a short form instead of handing you to another site. It needs 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 has to be the plain https address of a named installation. DataPipe rejects anything else — no http, no address with a username or password in it, no non-standard port, no IP address, and no internal or single-word hostname. That is because the DataPipe server itself makes authenticated requests to whatever you enter.

DataPipe checks the token against your installation before saving it, so an expired or mistyped token is refused at the point you paste it rather than at the first participant's submission.

When the credential for an experiment's provider is no longer usable, 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 temporary provider failure is queued and retried; a lapsed credential is not something a retry can fix.

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 on the next submission that needs it, a few minutes ahead of expiry. Neither needs anything from you.

Dataverse cannot.

A Dataverse API token has no renewal mechanism, so it eventually expires — commonly a year after you create it — and only you can replace it. DataPipe reads the expiry date from your installation each time you create an experiment on Dataverse, and names the date on that form when the token expires in the next 60 days. Dataverse does not show the expiry anywhere in its own interface, which is why DataPipe reports it. 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 lapsed still shows as connected — the connection exists, it just no longer works — so replacing it is a two-step action 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 are unaffected. Each one keeps writing to the Drive folder, Dataverse dataset, or Zenodo deposition it already has, and submissions that failed while the credential was lapsed are retried automatically — as long as they have not already used up their five attempts, which takes about 31 hours from when they were queued.

If a one-click authorization does not come back — you left the tab sitting, or opened the link twice — start it again from the account page. The link DataPipe hands to the provider works once, and expires ten minutes after it is created.

What happens to the 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.

All it deletes is that provider's stored credential. Your other connections, your experiments, and everything already written to 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 whose collection is currently paused.

A legacy OSF connection is the exception: it is not managed here, and it cannot be disconnected from this screen.

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