You can find the interactive Local API documentation here
Ooh, this is getting the creative juices flowing. Some ideas for endpoints/parameters and potential usecases:
- title parameter for the track endpoint to search for a specific track rather than specifying the ID.
- Potentially an āinplaylistā parameter for /track/ to only return a track if itās in a playlist. Alternatively, when we have an endpoint for playlists we could specify specific playlist IDs.
Things like this could power a song request tool for my twitch stream where the song request chatbot could poll Lexicon to verify if I have the song or not
3 Likes
Absolutely! Iām only just getting started with the API. It will grow over time. I just felt like making the base for it with the docs. More soon! (doing too many things at the same time right now :D)
This looks very good for a first pass.
I was thinking about doing a script that would automate imports when certain criteria are metā¦ I have a few things in mind (rounded BPM, cue point analysis), and it looks like i have almost everything I needā¦
I think I can do mostly everything with this APIā¦
I think I would query the track endpoint, and get any tracks without cue or tempo markers, and anything incomingā¦ and run processing on those using actionsā¦
I see the actions rely on selected tracksā¦ I canāt see where I would be able to query, then select tracks based on criteria (incoming = 1)ā¦ and other thingsā¦
Where would I do that?
Other than that, I think I could write a pretty decent automation.
1 Like
The API is very much in progress so I still have to add lots of endpoints and options.
I think an endpoint to execute recipes on a list of tracks would be an excellent idea.
Give me some time for that 
Iām building the API when I find some time here and there. There is a lot to document too.
Working on a Python wrapper for the API 
Thereās an error in the GET /playlists documentation. The example response body shows the same response as GET /playlist. I.e. it shows a single playlist with track ids, rather than the nested structure and root folder.
Also Iām kind of unclear on how the sort parameters work for GET /tracks.
The āTry it outā button tries to do ā&sort=id&sort=typeā but returns an error:
{
āmessageā: āāsortā must be an array, value: typeā,
āerrorCodeā: 5
}
Iāve tried all sorts of different ways of formatting this query and canāt get any sorting to return without errorā¦
Also found a bug in the GET /playlist API. When choosing the root folder (I believe this is always id:1) trackIds is not de-duplicated. In my library of 2564 tracks, trackIds for root is 34467 itemsā¦ Any other folder seems to work okay.
Some notes on GET /playlist-by-path:
GET /playlist on the ID of a folder returns a trackIds list with all the tracks it contains, but GET /playlist-by-path on a folder returns empty trackIds.
GET /playlist-by-path requires a type parameter, the documentation seems to say this is optional (at least the dropdown gives an option for --). I get this is because there could be name overlap, but I think it would be nicer to not require a type and instead throw an error if there is a name overlap and no type?
Sort works like this: sort[]=title&sort[]=artist
Iāll look into the rest
Yeah, thatās one of the things I tried.
Using the example from the documentation and changing the url to have brackets:
/search/tracks?source=non-archived&filter[artist]=Daft Punk&filter[bpm]=>%3D120&fields=artist&fields=title&fields=bpm&sort[]=title&sort[]=artist
Returns:
{āmessageā:āāsortā must be an array, value: [object Object]ā,āerrorCodeā:5}