Everything the console does, the API does.

A REST API over catalogue, delivery, rights, royalties and payouts — specified in OpenAPI, enforced by the build, and public. You can read it before you talk to anyone.

Four of them, for a start

Real endpoints, and the shapes they actually return.

GET/api/v1/releases200 OK

Paginated, filterable by status. `editable` is computed for the caller rather than left for you to re-derive from `status` — the rule differs between an artist and a console, and duplicating it client-side is how the two drift.

[
  {
    "id": 4471,
    "title": "Slow Monsoon",
    "release_type": "ep",
    "status": "live",
    "editable": false,
    "upc": "0198004417713",
    "external_id": "NW-2026-0114",
    "artwork_url": "https://…/artwork/4471.jpg",
    "created_at": "2026-01-14T09:22:41Z",
    "submitted_at": "2026-02-02T11:04:08Z",
    "went_live_at": "2026-03-14T00:00:00Z"
  }
]

Every path, field and status above is the real one. The full reference is an OpenAPI document the build refuses to let drift — an endpoint added without documentation fails the test suite.

Where each part standsLiveIn buildRoadmap

REST API

Live

Everything the console does, the API does. It is specified in OpenAPI and the specification is a build gate — adding an endpoint without documenting it fails the test suite, so the documentation cannot drift away from the implementation. It is also public. Most platforms in this category market an API and then issue the documentation under an account, which means you cannot evaluate the thing you are being sold until after you have committed to a sales process.

Releases, tracks, contributors, composers, artists, labels, stores, statements and tickets
An OpenAPI specification that the test suite enforces against the routing table
Consistent pagination, filtering and error shapes across every resource
Readable before you talk to anyone — not issued under an account after a sales call
Nested resources where the domain is nested — a track's contributors live under the track
Idempotent writes where a retry would otherwise duplicate

Machine keys & end-user tokens

Live

Your servers and your artists are not the same caller and should not share a credential. Machine keys are issued per account and can be refused centrally; end-user tokens are how an artist's own session reaches the API, and are untouched by that.

Per-account machine keys, mintable by the account owner
Separate short-lived tokens for end-user sessions
A central per-account switch that refuses machine keys without revoking anything
Scoped access — every request resolves to exactly one account
Full request auditing per key

Webhooks & events

In build

Release state changes, delivery results, QC verdicts, statement availability and payout events pushed to your endpoint, signed so you can verify them, and retried on a published schedule when your endpoint is down.

Signed payloads with a verifiable signature header
Retries on a published backoff schedule with a dead-letter view
Per-account endpoint configuration and event subscription
Delivery attempts visible in the console, replayable by hand
The same event stream that drives the console's own notifications

Typed clients & sandbox

In build

The specification is machine-readable, so the client types are generated from it rather than written by hand. A sandbox account gives you realistic responses without touching a live catalogue or a real store.

TypeScript types generated directly from the OpenAPI specification
A sandbox account with realistic data and no delivery side effects
Example requests for every endpoint, kept in step with the specification
Versioned endpoints — a breaking change is a new version, never a surprise
Machine-readable discovery so agents and crawlers can find the specification

DDEX & bulk ingestion

Roadmap

Established labels and aggregators speak DDEX, and the industry is mid-migration — the current suite is ERN 4.3.x, plenty of the supply chain still runs 3.x, and the platforms that matter accept both. Speaking both, in and out, removes the integration project that would otherwise sit between you and a catalogue that wants to move.

ERN ingestion and generation across both the 3.x and 4.3.x families
Batch delivery over SFTP, which is still how most of this supply chain actually moves
Per-partner conformance testing, because DDEX conformance is agreed between two parties — there is no certificate to hold
Store-specific packaging where a destination does not speak DDEX at all, which several do not
Identifier reconciliation against the existing catalogue, keyed on our own identifiers rather than trusting an incoming ISRC
A validation report rather than a silent partial import

Why the specification is a build gate

Adding an endpoint without documenting it fails the test suite. That sounds like an internal detail and it is the whole point: it is the only arrangement under which a reference cannot quietly drift away from the implementation, which is the normal end state of hand-maintained API docs. It is also why we can publish the specification rather than issuing it under an account after a sales call — we are not managing the gap between what it says and what is deployed, because there is not one.

Talk to us about developer api

There is no price list on this site and no self-serve sign-up for the platform. Tell us what you are running today and what you want to run it on, and we will tell you plainly whether this fits.

Talk to our team [email protected]

Every conversation starts here. There is no price list on this site — what this costs depends entirely on what you need it to do.