Development/XML Web Service/Version 2

From MusicBrainz Wiki
< Development‎ | XML Web Service
Revision as of 23:52, 11 May 2011 by Dremora (talk | contribs) (Introduction)

XML Web Service v2

This is my proposal on how V2 of the XML_Web_Service should work. --warp.

NOTE: As of the beta 2 release on 2010-06-21, most of what is documented below has been implemented.


We have six resources on our web service which represent core entities in our database:

 artist, label, recording, release, release-group, work

We also provide a web service interface for the following non-core resources:

 rating, tag, collection

And we allow you to perform lookups based on other unique identifiers with these resources:

 discid, puid, isrc, iswc

On each entity resource, you can perform three different GET requests:

 lookup:   /<ENTITY>/<MBID>?inc=<INC>
 browse:   /<ENTITY>?<ENTITY>=<MBID>&limit=<LIMIT>&offset=<OFFSET>&inc=<INC>
 search:   /<ENTITY>?query=<QUERY>&limit=<LIMIT>&offset=<OFFSET>

Of these:

  • Lookups, Non-MBID lookups and Browse requests are documented in following sections.
  • Searches are implemented by the search server and are documented at Next_Generation_Schema/SearchServerXML.
  • ratings and tags are not currently documented for /ws/2.


You can perform a lookup of an entity when you have the MBID for that entity:

 lookup:   /<ENTITY>/<MBID>?inc=<INC>


The inc= is parameter allows you to request more information to be included about the entity. Any of the entities directly linked to the entity can be included.

 /ws/2/artist            recordings, releases, release-groups, works
 /ws/2/label             releases
 /ws/2/collection        releases
 /ws/2/recording         artists, releases
 /ws/2/release           artists, labels, recordings, release-groups
 /ws/2/release-group     artists, releases

All lookups which include release-groups allow a type= argument to narrow down the release-groups. All lookups which include releases also allow the type= argument, and a status= argument is allowed.

Note that the number of linked entities returned is always limited to 25, if you need the remaining results, you will have to perform a browse request.

inc= arguments which affect subqueries

Some additional inc= parameters are supported to specify how much of the data about the linked entities should be included:

 - discids           include discids for all media in the releases
 - media             include media for all releases, this includes the # of tracks on each medium.
 - puids             include puids for all recordings
 - isrcs             include isrcs for all recordings
 - artist-credits    include artists credits for all releases and recordings
 - various-artists   include only those releases where the artist appears on one of the tracks, 
                     but not in the artist credit for the release itself (this is only valid on a
                     /ws/2/artist?inc=releases request).

Misc inc= arguments

 - aliases                   include artist, label or work aliases
 - tags, ratings             include tags and/or ratings for the entity (not valid on releases)
 - user-tags, user-ratings   same as above, but only return the tags and/or ratings submitted by the specified user

Requests with user-tags or user-ratings require authentication. You can authenticate using HTTP Digest, use the same username and password used to access the main website.


inc= arguments to include relationships work exactly like they do in /ws/1:

 - artist-rels
 - label-rels
 - recording-rels
 - release-rels
 - release-group-rels
 - url-rels
 - work-rels

Non-MBID Lookups

Instead of MBIDs, you can also perform lookups using several other unique identifiers. However, because clashes sometimes occur, each of these lookups return a list of entities (there is no limit, all linked entities will be returned, paging is not supported).


 lookup: /discid/<discid>?inc=<INC>&toc=<TOC>

A discid lookup returns a list of associated releases, the 'inc=' arguments supported are identical to a lookup request for a release.

If there are no matching releases in MusicBrainz, but a matching CDStub exists, it will be returned. This is the default behaviour. If you do not want to see CD stubs, pass 'cdstubs=no.' CD stubs are contained within a <cdstub> element, and otherwise have the same form as a release. Note that CD stubs do not have artist credits, just artists.

If you provide the "toc" query parameter, and if the provided discid is not known by MusicBrainz, a fuzzy lookup will done to find matching MusicBrainz releases. Note that if CD stubs are found this will not happen. If you do want TOC fuzzy lookup, but not cdstub searching, specify "cdstubs=no". For example:


Will look for the disc id first, and if it fails, will try to find tracklists that are within a similar distance to the one provided.

puid, isrc

 lookup: /puid/<puid>?inc=<INC>
 lookup: /isrc/<isrc>?inc=<INC>

puid and isrc lookups return a list of recordings, the 'inc=' arguments supported are identical to a lookup request for a recording.


 lookup: /iswc/<iswc>?inc=<INC>

An iswc lookup returns a list of works, the 'inc=' arguments supported are identical to a lookup request for a work.


Browse requests are a direct lookup of all the entities directly linked to another entity. (with directly linked I am referring to any relationship inherent in the database, so no ARs). For example, you may want to see all releases on netlabel ubiktune:


Note that browse requests are not searches, in order to browse all the releases on the ubiktune label you will need to know the MBID of ubiktune.

Linked entities

The following list shows which linked entities you can use in a browse request:

 /ws/2/artist            recording, release, release-group, work
 /ws/2/label             release
 /ws/2/recording         artist, release
 /ws/2/release           artist, label, recording, release-group
 /ws/2/release-group     artist, release

As a special case, release also allows track_artist, which is intended to allow you to browse various artist appearances for an artist. It will return any release where the artist appears in the artist_credit for a track, but NOT in the artist_credit for the entire release (as those would already have been returned in a request with artist=<MBID>).

〜 I think track_artist as described above is important, otherwise you will get client software requesting all recordings for an artist, followed by release requests for each of the recordings found earlier. --warp.

Release-groups can be filtered on type, and releases can be filtered on type and/or status. For example, if you want all the Live Bootleg releases by Metallica:


Or all albums and EPs by Autechre:


Note that filtering is mandatory, if you don't specify type or status the release and release-group resources will not return any results.


Browse requests are the only requests which support paging, any browse request supports an 'offset=' argument to get more results. Browse requests also support 'limit=', the default limit is 25, and you can increase that up to 100.


Just like with normal lookup requests, the server can be instructed to include more data about the entity using an 'inc=' argument. Supported values for inc= are:

 /ws/2/artist            aliases
 /ws/2/label             aliases
 /ws/2/recording         artist-credits
 /ws/2/release           artist-credits, labels
 /ws/2/release-group     artist-credits
 /ws/2/work              aliases

In addition to the inc= values listed above, all entities (except release) support:

 tags, ratings, user-tags, user-ratings
〜 we probably want to allow a few more inc= arguments here, though we can always add more later. --warp.

Release Type and Status

Any query which includes release-groups in the results can be filtered to only include release groups of a certain type. Any query which includes releases in the results can be filtered to only include releases of a certain type and/or status. Valid values are:

 status     official, promotion, bootleg, pseudo-release
 type       nat, album, single, ep, compilation, soundtrack, spokenword, interview, audiobook, live, remix, other

Submitting data

You can use the web service to submit certain kinds of data. Currently tags, ratings, PUIDs and ISRCs can be entered through the web service.


All POST requests require authentication. You should authenticate using HTTP Digest, use the same username and password you use to access the main website. The realm is "webservice".

POST requests should always include a 'client' parameter in the URL (not the body). The value of 'client' should be the ID of the client software submitting data. This has to be the application's name and version number, not that of a client library (client libraries should use HTTP's User-Agent header). The recommended format is "application-version", where version does not contain a - character.

User Data

You can submit tags and ratings through the web service using POST requests. As described above, client software needs to identify itself using the 'client=' parameter. In the following examples I will use '' as the client identifier, this is obviously a fictitious client.


To submit tags, perform a POST request to the /ws/2/tag url, like this:


The body of your request should be an XML formatted list of entities with <user-tag> elements. You can validate your XML request against our schema (

An example request is reproduced below:

<metadata xmlns="">
        <artist id="a16d1433-ba89-4f72-a47b-a370add0bb56">
        <recording id="047ea202-b98d-46ae-97f7-0180a20ee5cf">

Because you're sending XML in the body of your POST request, make sure to also set the Content-Type to "application/xml; charset=utf-8".

For examples, see User:kuno/ws/2/examples.


To submit ratings, perform a POST request to the /ws/2/rating url, like this:


The body of your request should be an XML formatted list of entities with <user-rating> elements. You can validate your XML request against our schema (

An example request is reproduced below:

<metadata xmlns="">
        <artist id="455641ea-fff4-49f6-8fb4-49f961d8f1ad">
        <recording id="c410a773-c6eb-4bc0-9df8-042fe6645c63">


To add and remove release from your collection perform a PUT and DELETE requests to /ws/2/collection/releases, respectively. For example:

   PUT /ws/2/collection/f4784850-3844-11e0-9e42-0800200c9a66/releases/455641ea-fff4-49f6-8fb4-49f961d8f1ad;c410a773-c6eb-4bc0-9df8-042fe6645c63?
   DELETE /ws/2/collection/f4784850-3844-11e0-9e42-0800200c9a66/releases/455641ea-fff4-49f6-8fb4-49f961d8f1ad;?

You may submit up to ~400 releases in a single request, separated by a semicolon (;), as the PUT example above shows. You are restricted to a maximum URI length of 16kb at the moment (which roughly equates to 400 release gids)

To get the contents of a collection, simple send a GET request to the releases resource:

   GET /ws/2/collection/f4784850-3844-11e0-9e42-0800200c9a66/releases

You can also perform a get request on the collection list, which will present you an of collections for the currently authenticated user, with the amount of releases in each collection:

   GET /ws/2/collection

PUID submission

PUIDs may be associated with recordings by issuing an XML POST request to:


The body of the request must be an XML document with a list of <recording>s in a <recording-list>, and a list of <PUID>s in a <puid-list> to be associated with the recordings. For example:

<metadata xmlns="">
        <recording id="047ea202-b98d-46ae-97f7-0180a20ee5cf">
                 <puid id="1d9e8ed6-3893-4d3b-aa7d-72e79609e386"/>
                 <puid id="2a232ad3-3893-4d3b-aa7d-72e79609e386"/>
        <recording id="66454646-b98d-46ae-97f7-0180a20ee5cf">
                 <puid id="78787887-3893-4d3b-aa7d-72e79609e386"/>

You can validate your XML request against our schema (

Barcode submission

Barcodes may be associated with releases by issuing an XML POST request to:


The body of the request must be an XML document with a list of <releases>s in a <release-list>, and a single barcode in a <barcode> element for each release. For example:

<metadata xmlns="">
        <release id="047ea202-b98d-46ae-97f7-0180a20ee5cf">

You can validate your XML request against our schema (

Upon issuing this request MusicBrainz will create a single edit in the edit queue for applying these changes. These changes will not be automatically applied, though they will be applied if either no one votes against your changes, or your changes expire (this edit is applied on expiration).

ISRC submission

[FIXME: write this bit --warp]

Identifying your application to the MusicBrainz Web Service

Starting on May 16th, 2011 the MusicBrainz Web Service requires all requests to have a proper User-Agent header that identifies the application and the version of the application making the request. Please do no use generic User-Agent strings like “Java/1.6.0_24″ or “PHP/5.3.4″ -- they do not allow us to identify the application making the request. On November 16, 2011 we're going to start blocking requests with generic User-Agent strings