The platform
Catalogue lifecycle
What happens to a work between your delivery and a society registration.
A work does not go straight from your delivery to a society. It passes through four stages, and you can see and correct it at every one. This page is the map.
Deliver
You send works, through the Catalogue Ingest API, by uploading a spreadsheet in the app, or from a connected Dropbox folder. We store what you sent, unchanged, and report every normalisation we applied.
Send the writers you represent, marked writer_controlled. You do not need the full roster: we
discover co-writers in the next stage.
Enrich
We fill gaps from industry sources: the MLC, ASCAP, BWARM, Apple Music, Spotify and the IPI registries. Enrichment never overwrites a value you delivered.
Review
We tell you what is missing and what looks wrong. You correct it, or you accept our suggestion. Nothing reaches a society without passing the checks for that destination.
Register
We build the submission file each destination accepts, and you deliver it.
Deliver#
Three routes in, all landing in the same place:
| Route | Best for |
|---|---|
| Catalogue Ingest API | A platform sending many artists' catalogues on a schedule. |
| Spreadsheet upload in the app | A one-off catalogue, or a client delivery you received as a file. |
| Dropbox connector | A folder your client keeps up to date, synced on our side. |
Whatever the route, we never silently change your data. Every transformation is reported back, and Validation and gaps lists them.
Enrich#
Enrichment fills what you did not send. It runs against external sources and writes only into empty fields.
The rules that matter:
- A value you delivered wins. Enrichment fills gaps. It does not overwrite your data.
- A title alone never creates a match. A title corroborates an identifier match; it cannot make one. This is deliberate: matching on title alone attaches other people's writers to your work.
- Confidence is recorded. Every enriched value carries where it came from and how sure we are.
- One catalogue at a time. A catalogue can have only one enrichment run in flight.
Enrichment runs against the MLC, ASCAP, BWARM, Apple Music, Spotify and the IPI registries, in that broad order of authority for rights data.
Review#
Two reports, and they answer different questions.
| Question | Example | |
|---|---|---|
| Gaps | What is missing? | This work has no ISWC. |
| Validation | What is present but wrong? | This IPI belongs to a different person. |
Neither blocks storage. Both block registration, because a society will reject the file or, worse, accept it and pay the wrong party.
The one to watch is a valid IPI belonging to the wrong writer. Nothing about the file looks wrong,
and the money goes elsewhere. We check delivered IPIs against the registries and flag the mismatch as
ipi_wrong_party.
Writers must be verified#
A writer we discovered, rather than one you delivered, cannot certify a work as ready. It has to be corroborated by an external source or confirmed by a person first.
This is why a catalogue can look complete and still not be ready to register. The fields carry values, but some are our guesses, and nobody has confirmed them.
Register#
Each destination has its own file format and its own minimum data. A work is included only when it passes that destination's checks.
Destinations lists all six and what each one requires.