Music Distribution API Platform for Labels

Music Distribution API lets record labels deliver releases to streaming stores programmatically, exactly once, with each label's data isolated.

21/21 stores received the first real release

<8 wks from kickoff to the first live release

2 delivery providers behind one adapter contract

Partner's Profile

Background

The client is a music-distribution joint venture building an API-first product for record labels. Labels need to push releases, with audio, artwork, metadata and splits, to streaming services programmatically through external delivery providers. The domain is unforgiving: re-sending a release creates a duplicate in stores and can get it taken down, so automatic failover between providers is forbidden. On top of that, the data of many labels lives in one shared database.

Objective

Build the platform core: a delivery pipeline that submits each release exactly once even when the infrastructure retries, one contract for plugging in delivery providers, integration points labels can trust, and tenant isolation that holds even when a developer forgets a filter. Around it, a label cabinet and an operations console for the client's team. The project started on 31 August 2026, with a second delivery provider planned after the first.

Solution

We built the core as an API-first backend driven by explicit state machines, about 14 of them documented: submission, per-store delivery, takedown, files, report import, outbox, webhook delivery, statements, split schemes, memberships and more. Every delivery provider plugs in through one adapter contract, and all provider calls go through a single gateway. Labels integrate via an OpenAPI schema with idempotency keys and signed webhooks; the client's team works in two React SPAs, a label cabinet and an operations console.

The hardest problem was exactly-once delivery on top of an at-least-once broker. RabbitMQ may redeliver a message, and a repeated provider call means a second release submission. We combined a PostgreSQL advisory lock, a "transfer started" mark written before the first provider call, and one release draft per provider. When the outcome of a call is ambiguous, the case goes to support for manual review instead of a blind retry. Events use a transactional outbox: they are written in the same transaction as the state change and count as published only after the broker confirms.

For a multi-tenant SaaS platform, isolation has two layers: an explicit filter in code plus PostgreSQL Row-Level Security, with the tenant set via SET LOCAL so it cannot leak through the connection pool. A forgotten filter returns an empty result, not another label's data.

Webhooks are signed with HMAC-SHA256; during secret rotation two signatures are valid, and an endpoint is disabled automatically after a series of failed deliveries.
Two-layer SSRF protection and an ffprobe-based audio format whitelist.
About 6,000 automated tests, including 68 adversarial tenant-isolation tests and 18 Playwright end-to-end specs.

On 22–23 October 2026, less than eight weeks after the 31 August kickoff, the first real release went through a production delivery provider, passed moderation, reached 21 of 21 stores and went live on storefronts such as Deezer. The second provider is moving from sandbox to pilot.

Exactly-Once Release Delivery

A broker redelivery must never become a second submission. An advisory lock, a 'transfer started' mark written before the first provider call and one draft per provider prevent duplicates; ambiguous outcomes go to support for manual review instead of a blind retry.

Two-Layer Tenant Isolation

Queries are filtered in code and again by PostgreSQL Row-Level Security, with the tenant set via SET LOCAL per transaction. A forgotten filter returns nothing rather than another label's data, and 68 adversarial tests probe leaks, side channels, routes, webhooks and jobs.

Signed Webhooks with Rotation

Label integrations receive webhooks signed with HMAC-SHA256. During secret rotation both the old and the new signature are valid, so integrations do not break. After a series of failed deliveries the endpoint is disabled automatically.

Transactional Outbox

Events are written in the same database transaction as the state change they describe and are marked published only after RabbitMQ confirms. A crash between the two steps loses nothing and publishes nothing that did not happen.

One Contract for Every Provider

Delivery providers plug in through a single adapter contract, and every provider call passes one gateway. The first provider delivers releases in production; a second one is moving from sandbox to pilot through the same contract.