OpenDeco API

Public endpoints expose released records and artifacts only. Draft research runs, unpublished datasets and private user data are not part of the public API surface.

No endpoint answers today. The release-scoped view this site reads is empty, and it cannot reach working or frozen rows even once they exist, so an API built on it inherits that limit in place of being trusted to respect it.

The read operations are already named and typed. Six of them cover sources, datasets and models, each with a typed request and a typed result.

Authentication is required only for services that need identity, quota or private account context. Creating a public OpenDeco account does not grant scientific write access.

No key exists to manage, because no service accepts one. Key management belongs to the portal, and the portal is unbuilt.

Most public research metadata is meant to stay readable without an account, so the first endpoints served will be the ones that need no credential at all.

Stable public endpoints are versioned where breaking changes would affect reproducibility or downstream research. Deprecated behavior remains documented for a defined migration period.

The contract package carries the shapes and the closed vocabularies a caller would branch on. Adding a value to a closed list is a change a downstream reader can see in a diff, which is the property a version number exists to protect.

No public endpoint is versioned yet, because none is served. A version scheme announced before the first endpoint would be a promise about code nobody has written.

Responses that represent scientific records expose stable identifiers and relevant version metadata so a downstream user can identify the dataset, model, release or artifact that produced the value.

Provenance sits in the record shapes and is not bolted onto them. A model record carries its implementation, its configuration, its verification level and its known calibration relationships. A dataset record carries its version, its checksums, its licence and its lineage.

Every list result states the instant it was generated and the origin it came from, so a fixture-backed view and a live view can never be mistaken for each other.

Rate limits protect the service. They do not create artificial scarcity. Bulk released artifacts should be downloaded once from their release location instead of reconstructed through thousands of repetitive API requests.

No number is published here, because no service runs and a limit invented in advance would be a guess a reader could build against.

The rule that will not change is the one above about bulk artifacts. A release bundle is a directory of files with a checksum manifest, and fetching it once is faster for the reader and cheaper for the service.

Manage API keys

This action belongs on this page and it has nothing to point at. Key creation and revocation live in the portal, the portal is unbuilt, and an account here would open a service that does not answer.

When the first endpoint is served, this section becomes the link to key management and the reference gains those endpoints beside their limits.