Read more here about our open protocols approach.

Special thanks to Berklee Trustee Dan Harple, Daan Archer, Gavin Nicol, Bas van Oostveen and the Context Labs team for tirelessly spearheading these efforts.

  • OMI members segmented in five working groups: 

  • Core Functions / Payments / Metadata / Platform Architecture / Identity

  • 5 Plenary Meetings to date

  • 3,000+ hours of conference calls

  • 50+ use cases submitted by members

  • First draft of Requirements Documentation agreed & ratified by members

  • API specifications (Minimum Viable Interoperability 1.0) developed

  • API released October 2017 and regularly updated/tweaked

  • API is designed to evolve naturally, and must evolve

  • Rough consensus and running code leads to standards that work

  • Multiple independent implementations exist and future work is already being identified


To help achieve OMI’s stated mission of assuring “proper compensation for all creators, performers and rights holders of music", OMI has identified the need to link recordings, musical works, and music rights holders and creators. The value of this is illustrated by this use case:

A complete list of ISWCs matched to recordings provided at an early point in the supply chain would provide a substantial boost when a label is first providing recording data to a digital partner (e.g., Amazon, Apple, Spotify, Tidal). It is sometimes a challenge to get a new DSP partner to pay in a timely and accurate manner - especially for the long tail. Providing a partner with compositional data matched to recording IDs can accelerate the process.

For example, a music distributor that licenses content from a record label usually needs to obtain additional rights from publishers or music rights societies on their behalf, but may not know from whom to obtain those rights. To solve this problem, the works associated with the recordings and ideally the entities that oversee their licensing must first be identified. Addressing this gap in the music industry is crucial for licensing and royalty payments, both in their current form and in advanced future interlinked forms, e.g. derivative licensing.

In short, the global music industry lacks a readily accessible and trustworthy Linkage of Sound Recording to Music Works and Creators/Contributors. As an open initiative, OMI is well placed to create consensus around specifications intended to solve this problem.


  • Currently it is difficult at best, to pay royalties from playback to composers

  • This is largely because it’s hard to discover who to pay/credit

  • Most reconciliation processes are manual


  • Query API enables automatic discovery of who royalties should be paid to

  • Optional registration capabilities

  • Support federation and auto-discovery of capabilities


  • OMI API adapters to MusicBrainz and Wikipedia

  • Federated API server connects to both

  • Federated/Direct connections are transparent to Apps


  • OMI API adapters to MusicBrainz and Wikipedia

  • Federated API server connects to both, and an attestation service

  • Change is transparent and engenders competition

All slides courtesy Gavin Nicol of Context Labs


API Reference Implementations

Use Cases by WG Use Case Provider # of Use Cases
Core Functions YouTube 1
Meta Interworking Viacom, YouTube, Round Hill 14
Identity, Security & Audit Services Universal, DDEX 30
Micropayment & Reporting Services Goldsmiths, 7Digital, Day One Investments 10
Ledger Services/Platform Architecture Marty Simon, C3 Note
Total 54

Use Cases by Market Vertical Use Case Provider # of Use Cases
Digital Service Providers (DSPs) Spotify, Viacom, YouTube 6
Electronic Dance Music (AFEM) AFEM 15
Music for Film and TV/Cue Sheets LSPA-member 1
Music for Creators: Providing Access to Data LSPA-member 1
Music Creators: Content Creators Coalition (C3) LSPA-member 9
Total 32