---
title: "Standard, enterprise, or streams: how to choose"
description: "Pick the right AudD recognition surface for your input: standard for a short clip, enterprise for long files, streams for continuous live audio."
slug: "/resources/concepts/standard-vs-enterprise-vs-streams"
section: "concepts"
keywords: [audd, standard endpoint, enterprise endpoint, streams, music recognition api]
---

# Standard, enterprise, or streams: how to choose

AudD exposes three recognition surfaces, and picking the wrong one is the
most common reason an integration is slower, more expensive, or simply
returns the wrong shape of data than it should. This page gives you a
decision rule, the reasoning behind it, and four worked inputs so you can
match your own task to a surface in a minute.

## TL;DR

Match your input to a surface:

- **One short clip, one song, you want the answer now** → standard endpoint
  (`POST https://api.audd.io/`). Under 2 seconds, 10 MB cap, one match.
- **A long file with many songs you want the full tracklist of** → enterprise
  endpoint (`POST https://enterprise.audd.io/`). No practical size cap, chunks
  server-side, bills per 12 seconds of audio.
- **Continuous live audio you want monitored over time** → streams
  (`addStream` plus callbacks or longpoll on `api.audd.io`). Radio, Twitch,
  YouTube live; results arrive as songs play.

If you can describe your input as "a file" you're choosing between standard
and enterprise. If you describe it as "a station" or "a channel" that never
ends, you're on streams.

## Why this matters

The three surfaces are not three tiers of the same product — they take
different inputs, return differently shaped responses, and bill on different
units. A 10 MB cap and a sub-2-second response is exactly right for a
"what's this song" button, and exactly wrong for a two-hour DJ set: the set
won't fit, and even if it did, the standard endpoint returns a single song,
not a tracklist. Conversely, sending a 5-second clip to the enterprise
endpoint works, but you're now reasoning about chunks and 12-second billing
units to get one answer the standard endpoint would have given you in one
call.

Streams are different again. They aren't a "file" call at all. You register a
URL once and AudD recognizes from it continuously, pushing results to you as
songs play. You can't poll a stream the way you POST a file; and you can't
hand a finite uploaded file to `addStream`. Choosing the surface first means
the rest of your code — request shape, error handling, billing model — falls
out of that one decision.

A useful mental split: standard and enterprise are **pull** (you hand over a
finite thing and get an answer back on the same call); streams are **push**
(you subscribe to an endless thing and answers arrive later, out of band).

## The standard endpoint: one clip, one answer

`POST https://api.audd.io/` is built for a short audio clip where you want
the single best match, fast.

- **Input:** a file (up to 10 MB) or a `url` to one. Audio formats: MP3, WAV,
  FLAC, M4A, OGG, AAC, WMA, AIFF.
- **Latency:** under 2 seconds.
- **Output:** one result object, or `result: null` on no match. `null` is a
  successful no-match answer, not an error — check for it explicitly.
- **Billing:** one request per call.
- **Auth:** `api_token` on every request. The public `test` token works here
  (10 requests/day, standard endpoint only).

This is the surface behind a "name that song" feature, a voice-assistant
music query, or identifying a single uploaded clip. You pass `return` to add
provider blocks (`apple_music`, `spotify`, `deezer`,
`musicbrainz`) when you want streaming links and richer metadata.

```python
from audd import AudD

audd = AudD("test")  # get your own token at dashboard.audd.io
result = audd.recognize("https://audd.tech/example.mp3")
print(result.artist, "—", result.title if result else "no match")
```

Reach for this surface whenever the clip is small and you want exactly one
song back. The moment the input is "longer than a clip" or "might contain
several songs," move to enterprise.

## The enterprise endpoint: long files, every song

`POST https://enterprise.audd.io/` handles audio and video that the standard
endpoint can't: full-length songs, podcasts, broadcasts, short-form videos,
and hours- or days-long DJ sets. It has no practical file-size cap and also
accepts the video formats MP4, AVI, MOV, MKV, and WebM.

The defining behavior: the server treats your file as a sequence of
12-second chunks, fingerprints them, and returns **one match per recognized
segment** — so a one-hour mix comes back as a tracklist, not a single song.
Each result carries `timecode` (position within the matched track),
`offset` (where the 12-second fragment starts in your file), and
`start_offset`/`end_offset` (the matched span within that fragment).

Billing follows the chunking: **one request per 12 seconds of audio
processed.** That's the cost lever, and it's why you control how much gets
scanned with these parameters:

- `limit` — upper bound on the number of chunks the server will recognize.
- `every` — how many chunks to scan in a row.
- `skip` — how many chunks to skip after each scanned run.
- `skip_first_seconds` — seconds to skip before the first chunk.
- `accurate_offsets` — set `"true"` for precise start/end offsets.

> **Always set `limit` during development.** The enterprise endpoint bills per
> 12 seconds of audio processed. An unbounded call on a multi-hour file can
> ingest hours of audio and produce hundreds of metered matches. Start with a
> small `limit` and raise it only once you understand the cost on your real
> inputs.

ISRC and UPC are returned on enterprise responses for accounts on a Startup
plan or higher. The `test` token does **not** work on this endpoint.

```python
matches = audd.recognize_enterprise(
    "https://audd.tech/djatwork_example.mp3",
    limit=10,  # cap metered chunks while developing
)
for m in matches:
    print(m.timecode, m.artist, "—", m.title)
```

## Streams: continuous live audio

Streams aren't a file call. You register a source once and AudD recognizes
music from it in real time, delivering results as songs play. This is the
surface for radio stations, Twitch channels, and YouTube live streams — any
source that runs continuously rather than ending.

The 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 it. The `url` accepts direct stream URLs (HLS, Icecast, DASH,
   m3u/m3u8) and the shortcuts `twitch:<channel>`, `youtube:<video_id>`, and
   `youtube-ch:<channel_id>`.
3. Receive results via **callbacks** (AudD POSTs to your URL) or **longpoll**
   (`GET https://api.audd.io/longpoll/`, you pull events). Manage sources with
   `getStreams`, `setStreamUrl`, and `deleteStream`.

By default a result callback fires after a song finishes playing and includes
the total played time. Set `callbacks="before"` on `addStream` to receive the
callback as soon as a song starts (you won't get the played-time total in that
mode). Stream notifications also flag problems with codes `650` (can't connect
to the stream) and `651` (only white noise, no music).

```python
audd.streams.set_callback_url("https://yourapp.example/audd-callback")
audd.streams.add(url="twitch:monstercat", radio_id=3249)
```

The `test` token does not work on streams; concurrent stream capacity is set
on the dashboard. How you receive results — callback versus longpoll — is its
own decision; see the related concept page below.

## Decision table

| Question | Standard | Enterprise | Streams |
|---|---|---|---|
| Endpoint | `api.audd.io/` | `enterprise.audd.io/` | `addStream` + callbacks/longpoll |
| Input shape | one short clip | one finite file (audio or video) | a continuous live source |
| File-size cap | 10 MB | no practical cap | n/a (live) |
| Songs returned | one best match | one per recognized chunk (tracklist) | one per song as it plays |
| Response model | synchronous, under 2 s | synchronous, may take seconds–minutes | asynchronous (push/pull over time) |
| Billing unit | per request | per 12 seconds of audio | per concurrent stream |
| `test` token works? | yes (10/day) | no | no |
| ISRC / UPC | Startup plan or higher | Startup plan or higher | contact api@audd.io |
| Typical use | "name that song" button | DJ set, podcast, UGC scan | radio / Twitch / YouTube monitoring |

## A decision tree in prose

Start with one question: **does your input ever end?**

If it never ends — a 24/7 radio station, a live Twitch channel, a perpetual
YouTube live stream — you're on **streams**. There's no file to hand over;
you register the source and subscribe to results.

If it does end, it's a file, so ask the next question: **is it a short clip
where one song is the answer?** If yes — a few seconds of audio, under 10 MB,
and you want the single best match — use the **standard endpoint**. It's the
fastest and simplest, one request, one result.

If the file is long, or might contain more than one song, or you specifically
want every track in it, use the **enterprise endpoint**. It chunks the file
and returns a tracklist. Then set `limit` (and consider `every`/`skip`) to
keep the per-12-second billing bounded.

One edge worth naming: a single full-length song (three to five minutes) is
still "a file that ends with one song in it." If it's under 10 MB and you only
need one match, the standard endpoint handles it. Use enterprise for the full
song only when you want every recognized segment or the file exceeds the cap.

## Worked example

Four concrete inputs, and the surface each one calls for.

**1. A 10-second clip recorded from a phone mic.** Short, one song, you want
the answer immediately. This is the textbook **standard endpoint** case: one
`recognize()` call, a result back in under 2 seconds, or `result: null` if
nothing matched. Don't overthink it — no chunking, no tracklist.

**2. A 2-hour recorded DJ set you want a full tracklist for.** It ends (so
not streams), it's long, and you want *every* track, not one. That's the
**enterprise endpoint**. Send the file or its `url`, and the server returns
one match per recognized 12-second segment with offsets you can turn into a
timestamped tracklist. Set `limit` while developing, and consider `every`/
`skip` to sample the set if you don't need every chunk. Expect ISRC/UPC on a
Startup plan or higher.

**3. A 24/7 community radio station.** It never ends — that's the tell.
**Streams.** Call `setCallbackUrl` once, then `addStream` with the station's
Icecast/HLS URL and a `radio_id` you choose. Results arrive continuously as
songs play; use `callbacks="before"` if you want a now-playing readout the
instant each song starts. A station is not a file, so neither file endpoint
applies.

**4. A TikTok video URL.** It's a single finite piece of content, and a
short-form video may carry one or more tracks. Pass the URL to the
**enterprise endpoint**, which parses the social URL server-side, extracts the
audio, and returns the recognized track(s). (If you had only a short audio
clip extracted from it and wanted a single match, the standard endpoint with
a `url` would also work — but for the video URL itself, enterprise is the fit.)

## Common mistakes

- **Sending a long file to the standard endpoint.** It rejects files over
  10 MB, and even when a file fits, you get one match — not the tracklist a
  long file usually warrants. Use enterprise for anything beyond a short clip.
- **Calling enterprise without `limit`.** Billing is per 12 seconds of audio.
  An unbounded call on a multi-hour file silently meters hundreds of chunks.
  Always cap `limit` in development.
- **Treating `result: null` (standard) as an error.** No-match is a successful
  response with a null result. Branch on it explicitly instead of routing it
  through your error handler.
- **Trying to poll a live stream like a file.** A continuous source has no end
  to POST. Register it with `addStream` and receive results via callbacks or
  longpoll; don't loop `recognize()` against it.
- **Using the `test` token on enterprise or streams.** It works only on the
  standard endpoint (10 requests/day). On the other two surfaces it will fail
  authentication — use a dashboard token.
- **Reaching for streams to process a finite recording.** If the audio ends,
  it's a file (standard or enterprise). Streams are for sources that don't end.

---

**Related**

- [Webhook callbacks vs longpoll for stream results](/resources/concepts/callback-vs-longpoll)
- [Build a copyright scanner for user-uploaded content](/resources/recipes/ugc-copyright-scanner)
- [Build a Shazam-style "name that song" feature](/resources/recipes/shazam-clone)
- [Get a tracklist for a DJ set](/resources/recipes/dj-set-tracklist)
- [Monitor radio airplay](/resources/recipes/radio-airplay-monitor)
- [Enterprise endpoint docs](https://docs.audd.io/enterprise)
- [Streams docs](https://docs.audd.io/streams)
- [API reference](https://docs.audd.io)