Returns a unix timestamp of when a locker, playlist, or preferences were last updated. Many external applications prefer to cache user locker data locally in order to optimize performance. By caching data retrieved from the MP3tunes Music API, an application can greatly increase response times within the application, therefore improving the user experience. In order to effectively cache user data locally, it is necessary to know when that data is no longer valid due to changes the user has made in a locker.

The lastUpdate call can be used to determine if data cached locally is still valid. A request to lastUpdate will return quickly, more quickly that just about any other call, and the size of the response is small. A high level view of a caching strategy would be:

  1. Fetch the last update time from the MP3tunes API
  2. Compare that time with locally stored version of the last update time. If this is the first call, the local version will be empty or 0.
  3. If last update time just fetched is more recent, fetch user data, cache it locally, and store the last update time.
  4. If last update time just fetched matches the value stored, use the user data cached locally.

An application can therefore make an intelligent decision as to how much data should be invalidated in a local cache and subsequently fetched again from MP3tunes. For example, if a user playlist last update time changes, the application would only have to fetch playlist data. Any other locker data (artists, albums, etc.) previously cached would still be valid.


sid (required): A valid session id, received from the "login" method.
partner_token (required): A valid partner token. See Overview for more information.
type (required): Specifies the type of last update time to return. Valid types are "playlist", "locker", and "preferences".
output (Optional): Your preferred output format. These include xml, and json.

Example Request:<sid>&type=locker

Example Response: