zenodo-rs

Async Rust client for core Zenodo workflows.

It covers deposition create/update/publish flows, safe draft reuse versus newversion, published-record lookup, latest-version resolution, and downloads behind a small typed API for automation and CI jobs built on top of the Zenodo REST API.

Start Here

• Use ZenodoClient for the main entrypoint.
• Use workflow for safe draft, publish, edit, and version helpers.
• Use records for published-record lookup, DOI resolution, and search.
• Use downloads for file and archive downloads.
• Use DepositMetadataUpdate and UploadSpec to describe what you want to publish.

Install

[dependencies]
zenodo-rs = "0.1"
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }

Optional features:

• checksums: validate Zenodo md5: checksums when downloading to a path
• native-tls: use reqwest with native-tls instead of the default rustls-tls

Read Example

use zenodo_rs::ZenodoClient;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = ZenodoClient::from_sandbox_env()?;
    let record = client.get_record_by_doi_str("10.5281/zenodo.123").await?;
    let _ = record.id;

    Ok(())
}

Publish Example

use zenodo_rs::{
    AccessRight, Auth, DepositMetadataUpdate, UploadSpec, UploadType, ZenodoClient,
};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = ZenodoClient::new(Auth::new("token"))?;
    let metadata = DepositMetadataUpdate::builder()
        .title("Example dataset")
        .upload_type(UploadType::Dataset)
        .description_html("<p>Example upload</p>")
        .creator_named("Doe, Jane")
        .access_right(AccessRight::Open)
        .build()?;
    let files = UploadSpec::from_named_paths([("artifact.tar.gz", "target/release.tar.gz")])?;

    let published = client
        .create_and_publish_dataset(&metadata, files)
        .await?;
    let _ = published.record.id;

    Ok(())
}

Authentication

• ZENODO_TOKEN is the standard env var for the production service at zenodo.org.
• ZENODO_SANDBOX_TOKEN is the sandbox equivalent for sandbox.zenodo.org.
• Write flows usually need deposit:write and deposit:actions.

Notes

Public download APIs use Zenodo IDs and selectors rather than raw URLs, and uploads require a known content length. For Zenodo-side behavior and token scopes, see the Zenodo developer docs.

Zenodo Limits and Retention

Zenodo's current upload docs say a record can contain up to 100 files and a total of 50 GB (50,000,000,000 bytes), with uploads up to 50 GB by default and additional quota that can bring a record up to 200 GB. If you need larger payloads than Zenodo is a good fit for, consider internetarchive-rs. Zenodo does not publish an SLA; instead, its principles page states a continuous-availability target of at least 99.7%, cites historical uptime of 99.98% (October 2019), and points to a public status page for live figures. Its preservation policy says items are retained for the lifetime of the repository, currently tied to CERN and described as at least the next 20 years; withdrawn records keep a tombstone page, DOI, and original URL. Zenodo only promises bit-level preservation, not future usability or understandability of deposited objects. zenodo-rs does not currently enforce the 100-file or 50 GB client-side limits: it validates duplicate/conflicting filenames and always sends an explicit Content-Length, but limit overflows are currently left for Zenodo to reject at request time. Sources: Manage files, Manage quota, General policies, Principles, Status page.