Zenodo Skill

Interact with the Zenodo REST API to deposit, publish, version, and search research artifacts. Zenodo issues a citable DOI for every published record.

When to use

• User wants to upload a dataset, code release, paper, poster, or other artifact to Zenodo
• User wants a DOI for a research output
• User wants to update an existing deposit or publish a new version
• User wants to search Zenodo for records

Setup

Two environments — pick one and stick with it during a session:

https://zenodo.org/api

https://sandbox.zenodo.org/api

Sandbox accounts/tokens are separate from production. Always test new workflows in sandbox first — published production records cannot be deleted.

Required token scopes:

deposit:write

deposit:actions

Export the token before running commands:

export ZENODO_TOKEN=...        # never inline the token in commands you show the user
export ZENODO_BASE=https://sandbox.zenodo.org/api   # or https://zenodo.org/api

If

ZENODO_TOKEN

Core workflow: deposit a new artifact

The deposit lifecycle is create → upload files → set metadata → publish. Each step is a separate API call; do them in order.

1. Create an empty deposition

curl -sS -X POST "$ZENODO_BASE/deposit/depositions" \
  -H "Authorization: Bearer $ZENODO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'

The response JSON contains two things you need to remember:

• id

  — the deposition id, used for metadata/publish/version actions

• links.bucket

  — the bucket URL for file uploads (new files API)

Capture them, e.g. with

jq

RESP=$(curl -sS -X POST "$ZENODO_BASE/deposit/depositions" \
  -H "Authorization: Bearer $ZENODO_TOKEN" -H "Content-Type: application/json" -d '{}')
DEPOSIT_ID=$(echo "$RESP" | jq -r .id)
BUCKET=$(echo "$RESP" | jq -r .links.bucket)

2. Upload files (bucket API — preferred)

The bucket API supports up to 50 GB total / 100 files per record. Use

--upload-file

curl -sS --upload-file ./data.csv \
  -H "Authorization: Bearer $ZENODO_TOKEN" \
  "$BUCKET/data.csv"

Repeat per file. For many files, loop in shell. The legacy

/files

3. Set metadata

Metadata goes via

PUT

upload_type

title

creators

description

references/metadata.md

upload_type

publication_type

embargo_date

Minimal example:

curl -sS -X PUT "$ZENODO_BASE/deposit/depositions/$DEPOSIT_ID" \
  -H "Authorization: Bearer $ZENODO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "title": "My dataset",
      "upload_type": "dataset",
      "description": "<p>A short description (HTML allowed).</p>",
      "creators": [{"name": "Doe, Jane", "affiliation": "Example Univ.", "orcid": "0000-0002-1825-0097"}]
    }
  }'

Read the response — Zenodo validates here and returns 400 with field-level errors if anything is missing or malformed. Fix and retry before publishing.

4. Publish

Publishing is irreversible on production (you can edit metadata later but cannot remove files or delete the record). Confirm with the user before this step unless they're on sandbox.

curl -sS -X POST "$ZENODO_BASE/deposit/depositions/$DEPOSIT_ID/actions/publish" \
  -H "Authorization: Bearer $ZENODO_TOKEN"

The response contains

doi

links.record_html

New version of an existing record

Use this when the user has previously published and wants to release updated data/code under the same concept-DOI.

# 1. Create new version draft (returns links.latest_draft)
curl -sS -X POST "$ZENODO_BASE/deposit/depositions/$DEPOSIT_ID/actions/newversion" \
  -H "Authorization: Bearer $ZENODO_TOKEN"

Then follow the bucket of the new draft (from

links.latest_draft

links.bucket

DELETE $BUCKET/<filename>

Discard a draft

curl -sS -X POST "$ZENODO_BASE/deposit/depositions/$DEPOSIT_ID/actions/discard" \
  -H "Authorization: Bearer $ZENODO_TOKEN"

Search published records

No token needed for public search.

curl -sS "$ZENODO_BASE/records?q=climate+model&size=10&sort=mostrecent"

Query syntax is Elasticsearch — fielded queries like

creators.name:"Doe, Jane"

communities:zenodo

resource_type.type:dataset

references/search.md

Conventions and gotchas

• Always check HTTP status. 201 = created, 202 = publish accepted, 400 = metadata error (read the body), 401 = bad token, 403 = wrong scope, 429 = rate limited.
• Rate limits: 100 req/min, 5000 req/hour for authenticated users. Watch

  X-RateLimit-Remaining

  .
• Never inline the token in commands you display — use

  $ZENODO_TOKEN

  . Don't write the token to files.
• Sandbox first. Suggest sandbox for any first-time workflow; switch to production only when the user explicitly confirms.
• Verify before publishing. GET the deposition and review files + metadata with the user before calling

  actions/publish

  on production.
• Large uploads: for files > a few hundred MB, consider doing the curl upload with

  --progress-bar

  and warn the user about time/bandwidth.

References

• references/metadata.md

  — full metadata schema, upload_type values, license codes, conditional fields

• references/search.md

  — search query syntax and useful filters

• references/examples.md

  — end-to-end shell scripts for common scenarios (dataset upload, software release, new version)