Reference

This section describes SeqDesk from the inside: the shape of the database, the layout of a running installation, and the HTTP endpoints you can call from a script instead of a browser. It is written for people who are integrating with SeqDesk, debugging it, or deciding whether it fits an existing infrastructure — not for people who are trying to submit an order.

Everything here is checked against the application source. Where a value is configurable, the page names the setting; where a value is derived, it names the code that derives it.

The mental model

There are two completely separate API surfaces, and confusing them is the most common source of wasted time:


seqdesk.org  (public, read-only, unauthenticated)
  /api/registry ............ pipeline catalog + package payloads
  /api/registry/mixs ....... curated MIxS checklists
  /api/registry/sequencing-tech  sequencing hardware catalog
  /api/version ............. latest release, consumed by the in-app updater
        │
        │  your instance pulls from it (installs, syncs, update checks)
        ▼
your-host  (your installation, session-authenticated)
  /api/orders, /api/studies, /api/samples ..... domain records
  /api/pipelines/** ........................... run control and monitoring
  /api/files/**, /api/orders/[id]/sequencing/** sequencing data
  /api/pipelines/weblog ....................... shared-secret webhook (no session)

The public endpoints are served by the seqdesk.org website and never see your data. The in-app endpoints only exist on your own host, sit behind a NextAuth session cookie, and are the ones that mutate anything.

Underneath both sits a single PostgreSQL database whose schema is defined in prisma/schema.prisma. Almost every API response is a projection of one or two models from that schema, so reading the Data Model first usually makes the API pages obvious.

Where to start

If you want to…	Start here
Understand what a record means before querying it	Data Model
Know where files, settings, and the database live on disk	Architecture
Script order, sample, or pipeline operations against your instance	App API
Mirror or extend the public pipeline catalog	Pipeline Registry API
Publish your own sequencing-hardware catalog	Sequencing Technology API

Data ModelEvery model in the Prisma schema, what it is for, its fields, its soft enums, and how the relations hang together.ArchitectureStack, request path, on-disk layout of a release install, where state lives, and the pipeline package contract.App APIHTTP endpoints on your own instance: form schemas, uploads, file operations, run control, weblog ingest, live stream.Pipeline Registry APIPublic seqdesk.org endpoints for discovering pipelines, downloading package payloads, and checking for releases.Sequencing Technology APIThe platform/device/flow-cell catalog, and the contract a custom registry must satisfy to be a sync source.

A naming trap worth reading once

The database model called Order is labelled Sequencing Order in the user interface. The model called SequencingRun is something else entirely — the physical run on the sequencer, with its barcode-to-sample assignment and QC metrics. One sequencing order contains zero or more sequencing runs.

The rename was display-text only, so every identifier you will meet in the API and the schema stays Order, orderId, orderNumber, /api/orders. Do not translate one into the other when reading these pages.

What this section is not

Reference pages describe mechanisms, not workflows. If you are looking for the task-oriented version:

Sequencing Orders & Samples — creating orders, sample metadata, order lifecycle
Pipelines & Analysis — choosing, launching, and monitoring pipelines
Configuration — every setting, its default, and where to put it
Administration — the admin screens that write most of the records described here