wavbeeOS

Drive distribution from your own systems.

Create releases, follow their delivery and read royalties and payouts from your own code.

Talk to us

What you get

For engineering teams connecting a catalogue, a royalty system or their own artist app to distribution. It replaces scraping a dashboard, or an API whose documentation you cannot read until after a sales call.

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.

  1. A documented REST API

    Every endpoint is in an OpenAPI specification, and an undocumented one fails our build. What you read is what is deployed.

    • Catalogue, delivery, rights, royalties and payouts
    • Types generated from the specification
    • The reference inside your console

  2. Keys you control

    Machine keys for your servers are separate from your artists' sign-in tokens. One can be switched off without touching the other.

    • Keys issued per account and revocable
    • Key creation and revocation recorded

  3. Test without risk

    A test key behaves exactly like a live one, and nothing it creates can reach a store. Clear the test data whenever you like.

    • Same endpoints, same validation, same responses
    • Test webhooks go only to your test endpoints

  4. Events, not polling

    Signed callbacks tell your server when something changes. Failed deliveries are retried for about a day.

    • A timestamp inside every signature, so a captured call cannot be replayed
    • Retried creates replay the stored answer under an Idempotency-Key

How it works

  1. Read the reference

    The explorer on this page walks through the real endpoints.

  2. Tell us what you are building

    Your platform, your volumes and what you want to automate.

  3. Build against a test key

    On your own account, with nothing able to reach a store.

  4. Switch to a live key

    The same calls, now on your real catalogue.

What’s coming

  • DDEX & bulk ingestionRoadmap

    Standards-based delivery in and out, for the partners that expect it.

Frequently asked questions

Can we read the documentation before we talk to you?

Yes. The reference on this page needs no account and no call first.

Can we build our own artist app on it?

Yes. Your artists sign in through the API with their own tokens, so your app can show their releases, statements and payouts.

Does a machine key open every endpoint?

No, on purpose. Calls that act for one artist need that artist's own token, and the reference marks which is which.

Does it work if we deliver on our own?

Yes. The API covers your catalogue, royalties and payouts whichever route your releases take to the stores.

Talk to us about the developer API

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

Talk to us[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.