wavbee Technologies

Distribution OS

Everything from an upload to a paid-out royalty.

The core system of record: catalogue, delivery, rights, royalties, payouts, billing and support. Built to answer any question about any release, years later.

The shape of it

One console, and everything a distributor runs inside it.

Release builder

Three tabs, autosave, validation panel

See this screen →

Royalty analytics

Revenue, units, RPM, drill-down

See this screen →

Review queue

Approve, return with a reason, or hold

Payout run

Threshold-triggered, multi-currency

Store manager

Per-account catalogue of destinations

Support desk

Threaded email, SLA clocks, shared mailboxes

A wireframe, on purpose — it makes no promises about colour or spacing that a screenshot would. Two of these screens carry enough to be worth seeing in full; the links open them.

Where each part standsLiveIn buildRoadmap

Catalog & metadata

Live

The system of record. Releases and tracks carry the complete contributor and composer graph rather than a flat text field, so a credit is an entity you can query, correct once, and deliver consistently to every store.

  • Releases, tracks, contributors, composers and recording versions as first-class records
  • 193 metadata languages and 429 genre styles, held as stable lookups rather than free text
  • ISRC, UPC/EAN, label, P-line and C-line, territory rules and sale dates
  • Roles and role groups, primary versus featured, ordered credits per release and per track
  • Corrections propagate — fix an artist once, every release carrying that credit follows
  • An artist de-duplication tool for the near-identical roster entries every migrated catalogue arrives with
  • A per-release status timeline, so "where is it" is a screen rather than a support ticket

Release builder

Live

The upload surface your artists actually touch. Release, Tracks and Distribution as three tabs over one record, saving as they type, with a live validation panel beside them. Submission unlocks only on a clean report — so a release does not reach your queue, or a store, in a state someone has to send back.

See release builderThe screen, in full, with the reasoning behind it.
  • Three tabs over one release — Release, Tracks, Distribution — with the tab held in the URL, so a reload or a Back lands where you were
  • Autosave with a visible save state; nothing is lost to a closed laptop
  • A validation panel listing every finding as blocking or advisory, and clicking one jumps to the exact field that raised it
  • Submit is gated on a clean report rather than accepting the release and rejecting it later
  • Contributor and composer pickers with roles, ordering and publishing shares — not free-text credit fields
  • Artwork and per-track audio uploaded straight to storage, with metadata read from the file itself
  • Per-track monetisation policy and distribution settings on their own tab

Delivery & store manager

Live

Delivery orchestration with a per-account store catalogue on top. The reach is a function of the relationships you hold, not of the software: through aggregator and partner routes the addressable network runs past 400 platforms and sub-platforms, and the delivery layer is built to target any endpoint you have a deal with. Every client sees only the destinations you enabled for them.

  • 400+ platforms and sub-platforms addressable through aggregator and partner routes
  • Not bounded by one contract — deliver through your supply agreement, your partner's, or ours
  • New destinations added as endpoints rather than as engineering projects
  • Spotify, Apple Music, YouTube Music, Amazon, Deezer, TikTok, Tidal, JioSaavn, Boomplay, Anghami and more
  • Per-account store catalogue — enable or disable destinations for each client
  • Takedowns, redeliveries and per-store status tracked as release events
  • Content ID and rights-management destinations handled alongside the audio stores

Your supply agreement, our platform

Live

The delivery relationship and the software that drives it do not have to come from the same company, and every credible platform in this category now says so. The difference is in the detail: this is not restricted to a higher plan tier, not limited to a short allowlist of endpoints, and the API you would automate it with is publicly documented rather than issued under an account. Where your upstream partner exposes an API, the whole system is built on top of it — artist dashboards, admin console, catalogue, analytics, royalties, payouts and support.

  • Bring your own distribution agreement — your contract, your rates, your relationship
  • Not a premium add-on and not a single-endpoint allowlist: every destination you hold a deal for
  • Delivery orchestrated through your upstream partner rather than replacing it
  • Where that partner exposes an API, the whole platform is built on it end to end
  • Artist-facing dashboards, admin console, analytics and royalty reporting on your supply chain
  • Or use ours — the same platform, with wavbee's own delivery relationships behind it
  • The choice is commercial, not technical: nothing in the software assumes one answer

Release review queue

Live

Quality control that exists now, rather than the automated engine described on the QC page. Releases arrive pre-validated by the builder, land in a review queue, and are approved, returned with a reason, or held. The automated checks being built plug into this queue rather than replacing it — the queue is where anything a machine should not decide alone ends up either way.

  • Pre-submit validation in the builder, so most problems never reach the queue
  • Findings carry a severity — blocking or advisory — rather than one undifferentiated list
  • Approve, return with a reason, or hold, with the whole exchange recorded on the release
  • Returned releases come back with the specific field named, not a general refusal
  • The queue the automated checks feed into, so adopting them changes the volume, not the workflow

Rights & splits engine

Live

Who owns what, who is owed what, and on what evidence — held against the release and track rather than in a spreadsheet somebody has to remember to update.

  • Per-release and per-track ownership with an account boundary enforced in the database
  • Contributor roles and role groups aligned to the standards stores expect
  • Composer and publishing metadata captured at track level
  • Monetisation policy per track and per destination
  • Every change written to an audit trail with the actor and the timestamp

Royalty pipeline

Live

Statements arrive in as many shapes as there are reporting parties. The pipeline normalises them into one table, deduplicates on the period and the reporting source rather than on a filename, and attributes every line to the recording it belongs to.

  • One normalised store for both major reporting patterns — per-transaction and per-summary
  • Deduplication on the reporting period and source, so a re-sent file cannot double-count
  • Attribution to ISRC, release, artist and account
  • Per-end-user statements published straight from the ingested data
  • Store, territory and period breakdowns available to the account holder and to you

Payouts & auto-pay

Live

Earnings become payments without anyone maintaining a parallel spreadsheet. A monthly run picks up every account whose latest statement clears the threshold, and the amount actually paid is recorded in the account's own currency.

  • Monthly automatic payout run driven by the latest settled statement
  • Payee accounts held per end user with the details the payment rail needs
  • Manual payout requests alongside the automatic run
  • Multi-currency — the paid amount is recorded in the currency it was paid in
  • A permanent payout log, queryable per account and per period

Analytics & reporting

Live

Reporting built on the ingested statements rather than on a separate analytics product, so the number an artist sees and the number you pay out are the same number from the same row.

See analytics & reportingThe screen, in full, with the reasoning behind it.
  • Trend charts over revenue and performance by release, track, artist and account
  • Ranked lists — top releases, top tracks, top territories, top stores for a period
  • An explorer for slicing the same data by dimension rather than only reading fixed reports
  • Per-end-user analytics surfaced inside the account holder's own console, not only yours
  • Drill-down to the individual statement line behind any figure
  • Exportable for finance, with the underlying royalty rows still addressable

Accounts, roles & isolation

Live

Every account is a hard boundary. Isolation is enforced in the query layer and asserted by a scoping matrix in the test suite, because 'we scope by account everywhere' is a claim that needs a machine checking it, not a convention.

  • Account-scoped everything — catalogue, users, statements, tickets, assets
  • Owner and member roles, with the last owner protected from removal
  • Per-account capability switches granted centrally — QC, escalation, store management, API access
  • Cross-account isolation asserted by an automated scoping matrix, not by convention
  • Impersonation for support, with a visible banner and a full audit record

Billing & invoicing

Live

The money layer, including the parts nobody demos. Currency is derived from the account's country rather than trusted from the client, mandates are never charged before the account is approved, and every redirect flow is confirmed server-side.

  • Three gateways — cards, UPI and wallet rails — behind one interface
  • Subscription and one-off pay-per-use charges on the same billing stack
  • Approval-gated mandates: nothing bills before an account is accepted
  • Invoices with Indian GST handling, line items and downloadable documents
  • Reconciliation sweeps recover any payment whose browser callback never arrived

Support desk

Live

A distribution platform is a support business wearing a technology coat. This is a full desk — inbound email parsed and threaded on message identity, shared and personal mailboxes, SLA clocks that stop and start with status.

  • Inbound email threaded on Message-ID and reference code, never on subject resemblance alone
  • Shared team mailboxes and personal mailboxes with per-member roles
  • Kanban queue with statuses, internal notes, and a public reply visible to the requester
  • SLA timers that pause and stop with ticket status
  • Spam learning, suppression filters, a knowledge base and dynamic intake forms

Asset storage & delivery

Live

Masters, artwork and documents held in object storage behind signed, expiring URLs, with large uploads going straight from the browser to the bucket so a big master never has to squeeze through the application.

  • Private bucket for masters, artwork, attachments and documents
  • Signed, expiring delivery URLs — no public object is ever the default
  • Direct-to-storage presigned uploads for large files
  • A separate public bucket for the assets that are genuinely public
  • Provider-agnostic — the storage layer is configuration, not code

Catalog migration

In build

Moving a live catalogue is the single biggest reason a label stays on a platform it has outgrown. Migration tooling matches on identifiers first, reports what it could not resolve, and never silently invents a record.

  • ISRC and UPC-first matching against the incoming catalogue
  • Bulk import of releases, tracks, contributors and identifiers
  • An explicit unresolved list rather than a best guess
  • Historical statement import so earnings history survives the move
  • Dry-run before anything is written

Publishing & works administration

Roadmap

The other half of the rights picture. A recording is one asset; the work behind it is another, with its own owners, its own registrations and its own money. Bringing works into the same system of record is the next major expansion — and it is partner-plural by design: publishing routes through whichever administrators and societies the client already works with, not through one we picked for them.

  • Works as records in their own right, linked to the recordings that embody them
  • Writer and publisher splits with controlled-composition handling
  • Society and CMO registration workflows, through whichever partner the client works with
  • Mechanical and performance royalty ingestion alongside the recording pipeline
  • One statement view across recording and publishing income

The parts nobody demos

Delivery and analytics are what every platform shows you. What decides whether you can actually run a business on one is the rest of it — reconciliation that recovers a payment the browser never confirmed, a support desk that threads email on message identity rather than subject line, statements that cannot double-count a re-sent file, and an isolation boundary a machine checks on every build. Those are all here, and they are here because operating without them hurt.

Talk to us about distribution os

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.

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