---
title: "AudD for PROs and rights organizations"
description: "How performing-rights organizations and collection societies use AudD to monitor broadcast and stream airplay for royalty allocation, identify works in large archives, and capture ISRC and UPC for logging."
slug: "/resources/for/pros-and-rights-orgs"
section: "for"
keywords: [audd, performing rights organization, collection society, airplay monitoring, royalty allocation, cue sheet, isrc]
---

# AudD for PROs and rights organizations

If you allocate royalties or administer rights on behalf of members, your work
runs on usage data: what was played, on which broadcast or stream, when, and
which registered work it corresponds to. This page is about getting that
usage data out of AudD — for performing-rights organizations and collection
societies specifically.

AudD is a music-recognition HTTP API over a database of 160 million
recordings. It can watch live broadcast and stream audio continuously,
identify works inside large content archives, and return the identifiers —
ISRC and UPC — that connect a recognition to a registered work.

## What you can do

### Monitor broadcast and stream airplay for royalty allocation

Royalty allocation needs a continuous, timestamped record of what played
where. The **streams** surface is built for exactly this: register the
broadcast and stream sources you cover, and AudD recognizes songs off them
around the clock and reports each recognition back to you.

- `addStream` registers each source you cover with its own `radio_id`, and
  `setCallbackUrl` or `GET /longpoll/` delivers each recognition as it
  happens — an independent, continuous log of plays across many sources.
  Stream URLs accept direct HLS, Icecast, and m3u/m3u8 URLs.
- `callbacks="before"` delivers a recognition at song start, so each row
  reflects the moment a play began rather than mid-song.
- To keep only the registered works you administer, match stream recognitions
  against a private **custom catalog** and drop the rest.

### Identify works in large content archives

Beyond live monitoring, you often have to identify what's inside archived
content — recorded broadcasts, submitted programs, long-form audio and video.
The **enterprise endpoint** (`POST https://enterprise.audd.io/`) chunks long
files server-side and returns one match per recognized segment, so a
multi-hour recording yields a full list of identified works.

- `recognize_enterprise` returns every recognized segment in a long
  recording — not just the first — each with `artist`, `title`, `label`, and
  a `timecode` marking the position within the matched recording.
- The endpoint bills per 12 seconds of audio processed; `limit`, `every`, and
  `skip_first_seconds` bound what you process per file, which keeps an
  archive-wide scan's metered cost under control.
- For thousands of files, batch the archive through recognition and write one
  row per identified work to your own log or database.

### Capture ISRC and UPC for cue-sheet-style logging

A usage log is only useful if each row ties to a registered work. The standard
artist/title pair is a starting point; the recording and release identifiers
are what let you match a play to your repertoire database.

- Artist + title alone is ambiguous against a large repertoire; enterprise
  responses include `isrc` (the recording's International Standard Recording
  Code) and `upc` (the release's Universal Product Code) on a Startup plan or
  higher — the keys you join on.
- Each match also carries `song_link`, a universal URL on lis.tn for the
  recognized recording — a stable, shareable reference per play in a
  cue-sheet-style record.
- If every match comes back with a null ISRC/UPC, check the plan tier: the
  identifiers are gated, and appear on Startup or above.

## Where to start

- [**Monitor radio airplay for your music catalog**](/resources/recipes/radio-airplay-monitor)
  — the streams workflow end to end: register many sources, record every
  recognition via callback or longpoll, and aggregate the rows. The same
  pattern drives royalty-allocation monitoring.
- [**Scan an archive of audio files and write metadata back**](/resources/recipes/bulk-audio-archive-scan)
  — walk a directory of recordings, identify each, and write artist, title,
  album, and ISRC to a resumable log — the basis of archive-wide work
  identification.
- [**Standard, enterprise, or streams: how to choose**](/resources/concepts/standard-vs-enterprise-vs-streams)
  — when to reach for live streams versus enterprise archive scanning for a
  given source.
- [**Recognition result fields**](/resources/reference/result-fields)
  — the exact fields a recognition returns, including `timecode`, `song_link`,
  and the provider metadata blocks, for building your log schema.

## Log a recognition off a stream

Streams recognition delivers each play to your callback URL or via longpoll.
The shape below pulls one batch of recognitions with longpoll and logs each as
a cue-sheet-style row.

```python
from audd import AudD

audd = AudD("your-api-token")  # token from dashboard.audd.io

# Pull recognitions delivered for one registered stream. longpoll() returns
# a poll handle; iterate its `matches` for each play as it arrives.
with audd.streams.longpoll(radio_id=101) as poll:
    for m in poll.matches:
        song = m.song
        if song is None:
            continue  # a notification, not a recognized play
        print(f"{m.timestamp}  radio={m.radio_id}")
        print(f"   {song.artist} — {song.title}  ISRC={song.isrc}  {song.song_link}")
```

Each event is one play on one registered source: the source's `radio_id`, the
recognized work, its identifiers, and a `song_link` you can store as a stable
reference. Filtering these events against a custom catalog of the works you
administer turns a generic now-playing log into a royalty-allocation feed.

> **Streams and enterprise require a real token.** The public `test` token
> works only on the standard endpoint (10 requests/day) — not on enterprise,
> not on streams. Get an account token at dashboard.audd.io before building
> the monitoring or archive flow.

For archive identification rather than live monitoring, send each recorded
file to the enterprise endpoint and log every returned match:

```python
matches = audd.recognize_enterprise(
    "https://audd.tech/example.mp3",
    limit=50,  # bound metered audio per file during development
)

for m in matches:
    print(f"{m.timecode}  {m.artist} — {m.title}  ISRC={m.isrc}")
```

---

**Related**

- [Monitor radio airplay for your music catalog](/resources/recipes/radio-airplay-monitor)
- [Scan an archive of audio files and write metadata back](/resources/recipes/bulk-audio-archive-scan)
- [Standard, enterprise, or streams: how to choose](/resources/concepts/standard-vs-enterprise-vs-streams)
- [Recognition result fields](/resources/reference/result-fields)
- [SDK docs](https://docs.audd.io/sdks)
- [API reference](https://docs.audd.io)