Services & Use Cases

Integrate Workflows

The Ekayana API is plain HTTP and JSON, with no SDK to install. Repository software, lab pipelines, and CI jobs can mint did:bio identifiers in the same run that produces the data, over the same documented endpoints that back the Ekayana Console.

Read the API docsAll services and use cases
Why?

Registration belongs in the ingest path

A registration step that sits outside the pipeline is the first thing dropped when output volume rises, which is when persistent identification matters most.

When did:bio registration runs as an API call inside an ingest workflow, every dataset gets its identifier at the moment it enters the repository. Nothing accumulates in a backlog. Metadata is read from the systems that already hold it, so records stay consistent instead of being retyped by hand.

Automation also changes what is feasible. The same call that registers one dataset registers ten thousand, and every record lands in the knowledge graph with resolvable, standards based metadata that keeps it findable and reusable long after the project ends.

Bridging matters as much as automation. Datasets held in Dataverse or Zenodo keep the DOIs and Handles they are already cited by, so integrating with Ekayana does not require migrating anything. Where data lives, who can read it, and how consent is enforced remain decisions your institution makes, because those constraints are enforced by the architecture rather than by a policy document.

What?

What the API covers

Identity, storage, BioAgents processing, and the repository bridges are all reachable over authenticated HTTP endpoints, simple enough to call from a shell script.

Plain HTTP and JSON

There is no SDK and no client library to keep in step with. Any language with an HTTP client can register did:bio identifiers, upload to IPFS, and query the knowledge graph: POST /api/upload returns a CID, POST /api/did returns a DID document.

Dataverse and Zenodo bridges

Datasets keep their DOIs and Handles, so existing citations, harvesters, and links keep resolving. POST /api/did/{id}/dataverse attaches a new did:bio to the DOI a dataset already has. See the Dataverse integration docs.

UCAN machine credentials

Delegate scoped, time bound, revocable UCAN capabilities to CI jobs and pipelines instead of sharing an account password. One runner can be revoked without rotating credentials anywhere else.

Dedicated institutional gateways

IPFS gateways on your own domain, with SSL, private access controls, and compliance reporting, so retrieval runs on infrastructure your institution operates.

Member only APIs and reports

Members reach additional endpoints and receive citation and usage reports covering the outputs their pipelines register, which is usually what an institution needs for its own annual reporting. See membership benefits.

GDPR controls that carry across bridges

Consent management, data portability, and right to erasure sit in the core architecture, and the same privacy controls apply to records bridged in from other systems.

How?

Wiring the API into a pipeline

Authenticate once, add the registration calls to the step that already writes your data, and read the results back from the same job. Every example below mirrors the documented API surface.

  1. Authenticate

    Signing in returns a session token that goes in the Authorization header of every later request. For CI runners and unattended pipelines, delegate a UCAN capability scoped to the resources and the time window that job needs, rather than storing an account password on the runner. Authentication and Access covers how requests are verified.

    bash

    # The API is plain HTTP and JSON. There is no SDK to install.
# Sign in once, then send the token on every request.
curl -X POST https://api.ekayana.com/api/signin \
  -H "Content-Type: application/json" \
  -d '{ "email": "pipeline@lab.example", "password": "..." }'
# -> { "token": "..." }

  2. Register from the ingest step

    Three calls do the work. Upload the file and take the CID from the response, mint a did:bio anchored in the Solana registry, and, when the dataset already lives in Dataverse, link the new identifier to its DOI. The DOI keeps resolving and citations keep counting against it, while the dataset gains content addressed provenance.

    javascript

    // 1. Upload the dataset. The CID comes back immediately.
const body = new FormData();
body.append('file', file); // e.g. dataset.csv

let res = await fetch('https://api.ekayana.com/api/upload', {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}` },
  body,
});
const { cid } = await res.json();
// Identical bytes always produce the same CID.

// 2. Mint a did:bio identifier for the dataset.
res = await fetch('https://api.ekayana.com/api/did', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${token}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    controller: 'did:bio:devnet:2T6zLFvMx7NJ...',
    public_key: 'z6MkfuN2vWAoHermh6vY6TgAJfwhBWZC...',
    metadata: {
      title: 'Coral bleaching survey 2026',
      researchers: [{ name: 'Ada Lovelace', role: 'PI' }],
      keywords: ['coral', 'bleaching'],
      license: 'CC-BY-4.0',
    },
  }),
});
const didDocument = await res.json();

// 3. Link the DID to the dataset's existing Dataverse DOI.
//    The DOI stays authoritative, so nothing downstream breaks.
await fetch(
  `https://api.ekayana.com/api/did/${didDocument.id}/dataverse`,
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${token}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ doi: '10.7910/DVN/EXAMPLE' }),
  }
);

  3. Check the results

    Pipelines need a feedback loop. Listing pinned content confirms that an upload landed, and BioAgents jobs run asynchronously, so poll by task id until the status comes back complete. Registrations are also visible in the Ekayana Console, and members receive citation and usage reports for what their workflows register.

    bash

    # Confirm the upload landed: list pinned content.
curl https://api.ekayana.com/api/pins \
  -H "Authorization: Bearer $TOKEN"

# BioAgents jobs are asynchronous. Poll by task id.
curl https://api.ekayana.com/api/bioagents/status/{task_id} \
  -H "Authorization: Bearer $TOKEN"

Who does the wiring

Build the integration yourself

The API reference covers identity, storage, BioAgents, and the repository bridges, with a worked example for each group of endpoints.

Work with a Registered Service Provider

Registered Service Providers are integrators and repository platforms that connect their own systems to Ekayana, so institutions do not have to build the wiring in house.

Integration targets

Systems Ekayana bridges

These are the systems the platform is built to connect to. In each case the existing record keeps the identifier it already has and stays where its community expects to find it.

Dataverse

Repository platform

Bidirectional sync, a persistent mapping from did:bio to DOI, and BioAgents enrichment of Dataverse metadata. Records stay in the catalogue your community already searches.

Zenodo

General purpose archive

Zenodo records keep their DOIs and gain a content addressed copy on IPFS, so provenance can be checked by hash rather than taken on trust. The platform overview describes how the two identifiers sit side by side.

Institutional repositories

Local ingest and cataloguing

Registration becomes one HTTP call inside the ingest and cataloguing flow you already run. Content is served back through a dedicated gateway on your own domain.

LIMS and lab pipelines

Instruments and acquisition systems

Instrument output goes from acquisition to identifier in a single run: upload the file, take the CID, mint a did:bio authorized by a UCAN credential scoped to that job alone.

Put registration inside the workflow

Start with the API documentation, or look at the Registered Service Provider program if you would rather not build the integration in house.

Read the API docsRegistered Service Providers