---
title: "How to build a music monitoring dashboard for rights holders"
description: "A practical guide to building a music monitoring dashboard that tracks your catalog across radio and live streams using AudD's streams API and SDKs."
slug: "/resources/articles/build-music-monitoring-dashboard-rights-holders"
section: "articles"
keywords: [audd, music monitoring, rights holders, streams, radio airplay, royalties, recognition api]
---

# How to build a music monitoring dashboard for rights holders

Rights holders leave royalties uncollected every year, and the cause is usually
incomplete tracking: music appears across thousands of radio stations and live
streams, and following it by hand doesn't scale.

A custom monitoring dashboard closes that gap. Instead of waiting on
performance-rights-organization (PRO) reporting that arrives months later and
misses smaller sources, you can track your catalog continuously and present the
data the way your team needs it. This guide walks through the architecture and
the recognition layer that makes it work.

## Why rights holders need custom monitoring

PRO reporting has gaps. Stations submit incomplete logs, digital platforms report
inconsistently, and international tracking varies by territory. A custom dashboard
fills those gaps by:

- **Covering sources PROs miss** — independent radio, internet radio, live
  streams.
- **Reporting in real time** — know about airplay as it happens, not months
  later.
- **Surfacing unlicensed use** — flag broadcasts in territories where you lack
  representation.
- **Centralizing the data** — one interface instead of scattered reports.

The technical foundation is three parts: recognition, storage, and
visualization. A recognition API handles the hard part — identifying songs — so
you don't build fingerprinting from scratch.

## Architecture overview

```
Live streams → AudD streams API → your callback → database → dashboard
```

For continuous radio and live-stream monitoring, the right tool is AudD's
**streams** mode, not one-off recognition calls. You register each source once
and AudD pushes matches to you as songs play, rather than you polling and
sampling a feed yourself. AudD recognizes against a catalog of 160 million
songs.

The streams flow uses methods on `api.audd.io`:

1. `setCallbackUrl` — register where results should be POSTed (set once).
2. `addStream` — add a source by `url` plus a `radio_id` integer you choose to
   identify the station.
3. Receive matches via **callbacks** (AudD POSTs to your URL) or **longpoll**
   (you pull events). Manage sources with `getStreams`, `setStreamUrl`, and
   `deleteStream`.

```python
from audd import AudD

audd = AudD("your-api-token")  # get a token at dashboard.audd.io

audd.streams.set_callback_url("https://yourapp.example/audd-callback")
audd.streams.add(url="https://stream.example/community-fm", radio_id=4012)
```

By default a result callback fires after a song finishes and includes the total
played time; set `callbacks="before"` on `addStream` to be notified the instant a
song starts. Stream notifications also carry problem codes — `650` (cannot
connect to the stream) and `651` (only white noise, no music) — so wire those
into alerting and a dead feed won't look like a quiet one.

## Database design for rights tracking

Structure storage around three tables:

**Catalog** — your recordings: song ID, title, artist, album, ISRC, ownership
percentage, territories.

**Detections** — recognition results: detection ID, song ID, source,
timestamp, played duration, and `score` (match confidence, available on the
Startup plan or higher).

**Sources** — monitored streams: source ID, name, type, market, contact info.

This supports queries like "every play of a song I own 100% of, on US stations,
in the last 30 days." Index the fields you query most — song ID, timestamp,
source ID — and partition the detections table by date once volume grows.

For custom-catalog matches, the result carries the integer `audio_id` you
assigned when you uploaded the track, which is how you tie a detection back to a
specific release you control. Any field the API returns that the SDK doesn't
model as a typed property is on the result's `model_extra` map in Python
(`extras` in Node) — store what you need from there.

## Building the dashboard interface

Different roles need different views:

### Real-time monitoring

Show recent detections as they arrive — title, artist, source, timestamp, and
`score`. Add filters by catalog subset, source type, or region so teams managing
large catalogs can focus on specific artists or labels.

### Usage analytics

Present historical data through charts: top recordings by play count, which
sources play your catalog most, geographic distribution, and trends over time.
Let users drill from a summary down to the individual detections behind it.

### Unlicensed-use alerts

Flag detections from sources not in your licensing database, or plays in
territories where you lack representation. Present them as actionable items with
source contact details and `score` so teams can prioritize follow-up.

### Export and reporting

Export to CSV for spreadsheets and JSON for downstream systems. Generate reports
formatted for PRO submission, including ISRC, play timestamps, and source
identification.

## Advanced features

### Monitoring your own catalog

To identify unreleased tracks, alternate versions, or recordings not in any
public database, upload your masters to a private **custom catalog**. You assign
each uploaded track an integer `audio_id`, and later matches return that
`audio_id` (often with `artist`/`title` null, since a private track has no
public-catalog metadata). This lets a label monitor its own releases against a
catalog it controls. The upload endpoint is provisioned on request — email
api@audd.io.

### Multi-territory ownership

Ownership varies by territory — a recording might be owned 100% in North America
but 50% in Europe. Store ownership percentages per territory so the dashboard can
attribute detections correctly and estimate royalties from territorial splits.

### Integration with existing systems

Expose API endpoints so your rights-management, royalty-processing, or CRM
systems can query monitoring data — to flag unlicensed use automatically or
trigger licensing outreach.

## Controlling cost at scale

Stream monitoring is billed per concurrent stream, so cost scales with how many
sources you watch at once rather than per detection. That makes it economical to
start small:

- **Prioritize by impact** — major-market stations and high-listenership feeds
  drive the biggest royalty impact; monitor those first.
- **Start with a pilot** — 2–3 strategically chosen sources validate the
  approach before broader rollout.
- **Scale by adding sources** — predictable per-stream billing means you grow
  capacity by adding streams, not by guessing at per-detection volume.

For current pricing, see [dashboard.audd.io](https://dashboard.audd.io).

## Getting started

Build the recognition layer first with a small pilot, confirm the matches are
accurate against your catalog, then expand. The streams API and SDKs handle the
identification; your work is the storage, the dashboard, and acting on the data.

Get a token at [dashboard.audd.io](https://dashboard.audd.io) and start with the
recipe below.

---

**Related**

- [Monitor radio airplay](/resources/recipes/radio-airplay-monitor)
- [Webhook callbacks vs longpoll for stream results](/resources/concepts/callback-vs-longpoll)
- [Standard, enterprise, or streams: how to choose](/resources/concepts/standard-vs-enterprise-vs-streams)
- [API reference](https://docs.audd.io)