Enterprise response and match fields

The enterprise endpoint (POST https://enterprise.audd.io/) processes longer audio — full-length songs, short-form videos, podcasts, broadcasts, DJ sets — by splitting the file into 12-second chunks server-side and returning every recognized track. Its response is shaped differently from the standard endpoint: result is an array of chunks, each carrying its position in the file and the songs found in it. This page documents that shape, the per-song fields, and the request parameters that control chunking. For the single-object standard response, see the recognition result fields reference.

Response shape

result is an array. Each element is one chunk:

Field	Type	Description
`offset`	string	The chunk’s position in the submitted file, `MM:SS` or `HH:MM:SS` — the start of the 12-second fragment this chunk covers.
`songs`	array	The songs recognized in this chunk. Usually one; can be several when audio blends overlap (for example, a DJ transition).

The top level also carries execution_time (a string such as "159.226763ms"), and status is "success" as usual.

{
  "status": "success",
  "result": [
    {
      "songs": [
        {
          "score": 81,
          "artist": "Tears For Fears",
          "title": "Everybody Wants To Rule The World",
          "album": "Songs From The Big Chair",
          "release_date": "2014-11-10",
          "label": "UMC (Universal Music Catalogue)",
          "timecode": "00:57",
          "isrc": "GBUM71403885",
          "upc": "00602547037169",
          "song_link": "https://lis.tn/NbkVb"
        }
      ],
      "offset": "00:00"
    }
  ],
  "execution_time": "159.226763ms"
}

Song fields

Each entry in a chunk’s songs array:

Field	Type	Description
`score`	integer	Match confidence, 0–100. Higher is stronger. Requires a Startup plan or higher.
`artist`	string	The track’s artist.
`title`	string	The track’s title.
`album`	string \| null	The album the recording appears on.
`release_date`	string \| null	The release date, `YYYY-MM-DD`.
`label`	string \| null	The record label.
`timecode`	string	Position within the matched track where this chunk aligns, `MM:SS`. A position in the reference recording, not in your file.
`isrc`	string \| null	International Standard Recording Code of the recording. Requires a Startup plan or higher.
`upc`	string \| null	Universal Product Code of the release. Requires a Startup plan or higher.
`song_link`	string	Universal link to the song’s page on `lis.tn`.
`start_offset`	integer	With `accurate_offsets=true` only. Start of the matched fragment, in milliseconds within the 12-second chunk (range 0–~12000). See below.
`end_offset`	integer	With `accurate_offsets=true` only. End of the matched fragment, in milliseconds within the 12-second chunk.

offset vs. start_offset / end_offset

These two locate a match at different scales, and confusing them produces timestamps that are off by minutes.

offset (on the chunk) is the position in the file you submitted of the start of the 12-second fragment that contains the match, formatted MM:SS or HH:MM:SS. It places the chunk in the overall file.
start_offset / end_offset (on the song, only with accurate_offsets=true) are positions in milliseconds within that 12-second fragment — not file seconds. They range from 0 to about 12000.

To get the file-absolute position of a match, parse the chunk offset to seconds and add the song’s start_offset divided by 1000:

file_seconds = parse_mmss(chunk.offset) + song.start_offset / 1000

For a chunk with offset "04:48" and a song with start_offset 3520, the match begins at 288 + 3.52 = 291.52 seconds into the file.

Request parameters

Sent as multipart/form-data. Supply audio with url (a file or page URL the server fetches) or file (a multipart upload). api_token is required on every request.

Parameter	Type	Description
`return`	string	Comma-separated metadata identifiers. The standard endpoint uses this to attach provider blocks (`apple_music`, `spotify`, …); on the enterprise endpoint, per-song results carry `isrc`/`upc` rather than provider metadata blocks.
`limit`	integer	Upper bound on the number of chunks the server will recognize. Always set this in development — see the warning below.
`every`	integer	How many chunks are recognized in a row.
`skip`	integer	How many 12-second chunks to skip after each recognized run. Combine with `every` to sample rather than scan exhaustively.
`skip_first_seconds`	integer	How many seconds to skip at the start of the file before recognition begins (the start time of the first chunk). Do not use together with `use_timecode`.
`use_timecode`	string	Set to `"true"` to use the time in a URL’s `t`, `time_continue`, or `start` parameter (when present) as `skip_first_seconds`. Do not use together with `skip_first_seconds`.
`accurate_offsets`	string	Set to `"true"` to get `start_offset` and `end_offset` on each recognized song.

Always set limit during development. The enterprise endpoint bills per 12 seconds of audio processed; an unbounded call can ingest hours of audio before it returns. Set limit to a small number while testing.

Notes

result is an array, not an object. Iterate chunks, then iterate each chunk’s songs.
A chunk can return multiple songs. Lower-score entries in the same chunk are usually overlapping or blended audio rather than separate placements.
The typed SDKs flatten the chunk array into a single list of matches, but each match carries the file-absolute position for you as start_seconds and end_seconds (seconds into your file). They apply the offset + start_offset/1000 formula above internally, and request accurate_offsets=true by default, so those seconds are precise — you don’t need the raw response or the chunk offset to place a match. The raw start_offset/end_offset remain available as the fragment-relative milliseconds. Use the formula directly only when calling the HTTP API yourself.
score, isrc, and upc require a Startup plan or higher. On lower plans these fields are absent from the response.
start_offset/end_offset are present only when the request sets accurate_offsets=true.

Related