> ## Documentation Index
> Fetch the complete documentation index at: https://docs.musixmatch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Publishing integration

> Submit publishing data for musical works, and read the rights and credits behind a recording

The Publishing API has two halves: **submit** works into the catalog, and **look up** the rights and
credits behind them.

**Submit.** Rights holders and publishers send copyright and ownership information for musical works
into the Musixmatch catalog — ownership and collection shares per territory, ISRCs, performers,
alternate titles, and the validity lifecycle of works already ingested. This supports royalty
collection workflows and keeps your works correctly matched across music sources.

**Look up.** Two groups of methods, matching the sidebar:

* **Recording** (`recording.*`). Administrators and credits for recordings, and the recordings of a
  musical work by ISWC.
* **Musical work** (`musicalwork.*`). The full publishing behind recordings, and the works credited to a
  writer.

The data comes from CWR registration and from our reconciliation of it.

## Concepts

Reading the lookup responses is much easier with four distinctions.

### Sound recording vs musical work

A **sound recording** is a specific captured performance, identified by ISRC. A **musical work** is the
composition it is a recording of, identified by ISWC. One recording can resolve to several musical
works, and one musical work has many recordings. Every lookup method crosses between the two in one
direction or the other.

### Ownership vs collection

**Mechanical ownership share** is a rights holder's share of the work, on a 0–100 scale. It carries
no territory: owning a share of a work means owning that share everywhere.

**Collection share** is what is collectible in a specific territory, which diverges from ownership
wherever a sub-publishing or administration deal puts collection in local hands. We hold it for
controlled chains only, so the collection reported for a work in a country is the controlled part of
it, never the whole work redistributed. A rights holder can carry a real ownership share and
contribute no collection at all.

### Bands vs exact shares

Shares come back as band labels — `0-30`, `30-70`, `70-100` — in both `mech_ownership_share` and
`mech_share`. The precise numbers are a separately priced add-on: set `options.exact_ownership` on
`musicalwork.recording.details.search.post` and the same fields carry the figure instead. A key
without that product gets a 403 for the option, not a silent downgrade.

<Info>
  A `null` share is not a zero: it means the data carries no share. A territory with nothing
  collectible is omitted from `collection` rather than reported as zero.
</Info>

### Rights vs credits

`administrator_list` answers who controls the publishing. `credit_list` answers who made the
recording — producers, engineers, players, composers, labels. They come from different pipelines and
will disagree about the same recording. That is expected: they answer different questions, and we do
not reconcile them.

## Response conventions

Every method answers over **HTTP 200**. The outcome of the call is `message.header.status_code`, and
a request we cannot run carries a prose `hint` beside a machine-readable `hint_code` in the same
header. Integrate against `hint_code` — the prose is free to change.

An empty result is a coverage gap, never an error: an ISRC, ISWC or IPI we hold nothing for is a
`200` with an empty list, not a `404`. A failed read is a `500` and never an empty list, so the two
can always be told apart.

The batch methods take **up to 25 recordings** and answer one entry per submitted recording, in
request order, so you can zip the response onto your request. Any bad input fails the whole
request with a `400`: there is no per-row invalid state. ISRCs and ISWCs are accepted hyphenated and
in lower case.

The paginated methods serve a **fixed page size of 25**. Sending `page_size` is a `400` rather than
being ignored, so a short page always means the end of the results.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.