[GH-ISSUE #535] API documentation

kerem commented

2026-02-26 02:33:01 +03:00

Owner

Originally created by @Phyks on GitHub (Feb 8, 2017).
Original GitHub issue: https://github.com/koel/koel/issues/535

Hi,

I was looking for a complete documentation of the actual Koel API, but I could not find any in the wiki. Not sure if I missed it somewhere, in such case I am really sorry.

If there is no such documentation, I think adding one somewhere, like in the wiki, would be a great addition!

Thanks!

Originally created by @Phyks on GitHub (Feb 8, 2017). Original GitHub issue: https://github.com/koel/koel/issues/535 Hi, I was looking for a complete documentation of the actual Koel API, but I could not find any in the wiki. Not sure if I missed it somewhere, in such case I am really sorry. If there is no such documentation, I think adding one somewhere, like in the wiki, would be a great addition! Thanks!

kerem

2026-02-26 02:33:01 +03:00

closed this issue
added the
[Status] Will Implement

[Status] Needs Review

[Type] Task
labels

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Feb 9, 2017):

Can I ask you what is your need for this API ?

I'm currently writing an Android client for Koel/Kutr and I'm currently documenting it (because I need it...). So it might be interesting to share the effort.

@X-Ryl669 commented on GitHub (Feb 9, 2017): Can I ask you what is your need for this API ? I'm currently writing an Android client for Koel/Kutr and I'm currently documenting it (because I need it...). So it might be interesting to share the effort.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@Phyks commented on GitHub (Feb 9, 2017):

Typically, to write some client on top of this API. Definitely, if anyone has some write-up of API documentation, it would be really interesting to share :)

@Phyks commented on GitHub (Feb 9, 2017): Typically, to write some client on top of this API. Definitely, if anyone has some write-up of API documentation, it would be really interesting to share :)

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Feb 9, 2017):

Ok. What kind of client (unless it's secret ;-) ?
Anyway, please have a look to this:
https://github.com/X-Ryl669/kutr/wiki/Communication-API

It's a WIP for now, since not all routes are described, only the one I'm using.

@X-Ryl669 commented on GitHub (Feb 9, 2017): Ok. What kind of client (unless it's secret ;-) ? Anyway, please have a look to this: https://github.com/X-Ryl669/kutr/wiki/Communication-API It's a WIP for now, since not all routes are described, only the one I'm using.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@phanan commented on GitHub (Feb 10, 2017):

Hm, looks like I need to resume my work on this: http://docs.koel.apiary.io/. Too bad Apiary doesn't allow you to create a team of collaborators with their free package. Anyone have a suggestion for a better tool?

@phanan commented on GitHub (Feb 10, 2017): Hm, looks like I need to resume my work on this: http://docs.koel.apiary.io/. Too bad Apiary doesn't allow you to create a team of collaborators with their free package. Anyone have a suggestion for a better tool?

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@Phyks commented on GitHub (Feb 10, 2017):

@X-Ryl669 no real project at the moment, it was more to see how my existing clients such as https://github.com/Phyks/ampache_react/ could be adapted to a Koel backend and to assess the features of Koel more widely (without digging too much in the code). Typically, how it will handle (very) large library and whether I could build some modules for other software to make use of Koel.

@phanan sorry, I've never used such tools. I either wrote plain wiki pages or generated doc based on Doxygen-like comments, whenever I had to document APIs.

Thank you both for the API overview!

@Phyks commented on GitHub (Feb 10, 2017): @X-Ryl669 no real project at the moment, it was more to see how my existing clients such as https://github.com/Phyks/ampache_react/ could be adapted to a Koel backend and to assess the features of Koel more widely (without digging too much in the code). Typically, how it will handle (very) large library and whether I could build some modules for other software to make use of Koel. @phanan sorry, I've never used such tools. I either wrote plain wiki pages or generated doc based on Doxygen-like comments, whenever I had to document APIs. Thank you both for the API overview!

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Feb 10, 2017):

@phanan Apiary allows for 5 collaborators per project in their free plan, IIRC.

A bit out of subject, but while documenting, I realized that the data is very large (and very redundant) and it's probably the cause for the slow bootstrap of the application (since it's downloaded each time, even if you already have the main application javascript in cache).

So, what do you think about reworking it so it's smaller. I'm thinking about this scheme:

Separate songs from albums and albums from artists. Since song have the album_id and albums have the artist_id, there's no need they stay so intricated. This would also clean the messy JS code to split them back in their respective stores.
Remove the created_at keys (it's a lot of useless information sent)
Use default value for missing fields (so instead of sending "image" : null for each artist), don't send the field. Same for boolean false (like is_compilation, only send if true)
Similarly for interactions, we could create 2 objects, one for liked = true and one for liked = false. This would limit to a list of "play_count" per song. In that case, it's probably even better to merge the interaction information back in the song object (so it avoid repeating the song id which is very large)
Last but not least, if keeping the interaction as-is, we could map an integer to each song (instead of such a large song id), we would save bytes. I think the idea above is better.
More long term, but split the data into multiple route, so it's possible to cache the data response (it does not change until you re-sync your media library). Only the interaction does change, so it would make more sense to have a separate route for it.

@phanan Would you accept a change in the API if it makes sense like the above ?

@X-Ryl669 commented on GitHub (Feb 10, 2017): @phanan Apiary allows for 5 collaborators per project in their free plan, IIRC. A bit out of subject, but while documenting, I realized that the `data` is very large (and very redundant) and it's probably the cause for the slow bootstrap of the application (since it's downloaded each time, even if you already have the main application javascript in cache). So, what do you think about reworking it so it's smaller. I'm thinking about this scheme: 1. Separate songs from albums and albums from artists. Since song have the album_id and albums have the artist_id, there's no need they stay so intricated. This would also clean the messy JS code to split them back in their respective stores. 2. Remove the `created_at` keys (it's a lot of useless information sent) 3. Use default value for missing fields (so instead of sending `"image" : null` for each artist), don't send the field. Same for boolean false (like `is_compilation`, only send if true) 4. Similarly for interactions, we could create 2 objects, one for liked = true and one for liked = false. This would limit to a list of "play_count" per song. In that case, it's probably even better to merge the interaction information back in the song object (so it avoid repeating the song id which is very large) 5. Last but not least, if keeping the `interaction` as-is, we could map an integer to each song (instead of such a large song id), we would save bytes. I think the idea above is better. 6. More long term, but split the `data` into multiple route, so it's possible to cache the `data` response (it does not change until you re-sync your media library). Only the `interaction` does change, so it would make more sense to have a separate route for it. @phanan Would you accept a change in the API if it makes sense like the above ?

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@Phyks commented on GitHub (Feb 10, 2017):

A bit out of subject, but while documenting, I realized that the data is very large (and very redundant) and it's probably the cause for the slow bootstrap of the application

That is in part something I wanted to check with the API documentation: how Koel was handling large databases, but did not yet have much time to go through the code.

For what it's worth, the guys behind Beets are working on an API specification for music servers, which could be useful: http://auraspec.readthedocs.io/en/latest/.

Also, @phanan I am not sure whether there is a real reason to have only a single data entrypoint and not dedicated entrypoints for artists, albums and songs, with pagination, and load the data in the UI only when needed (and eventually keep a cache)?

@Phyks commented on GitHub (Feb 10, 2017): > A bit out of subject, but while documenting, I realized that the data is very large (and very redundant) and it's probably the cause for the slow bootstrap of the application That is in part something I wanted to check with the API documentation: how Koel was handling large databases, but did not yet have much time to go through the code. For what it's worth, the guys behind Beets are working on an API specification for music servers, which could be useful: http://auraspec.readthedocs.io/en/latest/. Also, @phanan I am not sure whether there is a real reason to have only a single `data` entrypoint and not dedicated entrypoints for `artists`, `albums` and `songs`, with pagination, and load the data in the UI only when needed (and eventually keep a cache)?

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Feb 10, 2017):

This mix the other issue report a bit.

Currently, (except for songs), Koel works offline (once loaded, of course). This is not possible with pagination.

There is nothing that prevents having multiple entry points, except that browser only use 2 connections to a server, so it'll add a big of lags to split all data other multiple entry points.

But, splitting data in 2 entrypoints: one that does not change (song+artist+album+settings+genres+playlists+users information) and another that does (interaction + software version mainly) would still work with the 2 connections limit from cold cache load, and still prevent having to resend the static information on later reload, yet providing the best of both cases.

@X-Ryl669 commented on GitHub (Feb 10, 2017): This mix the other issue report a bit. Currently, (except for songs), Koel works offline (once loaded, of course). This is not possible with pagination. There is nothing that prevents having multiple entry points, except that browser only use 2 connections to a server, so it'll add a big of lags to split all data other multiple entry points. **But**, splitting data in 2 entrypoints: one that does not change (song+artist+album+settings+genres+playlists+users information) and another that does (interaction + software version mainly) would still work with the 2 connections limit from cold cache load, and still prevent having to resend the static information on later reload, yet providing the best of both cases.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Feb 10, 2017):

@Phyks If I understand correctly AURA is a REST api for Beets' music library organizer and player daemon. I don't see any client consuming AURA currently (except for a WIP dashboard web interface) and if there was one, it would except to send control command to a server to play some tracks, not to fetch and play the track locally on the client (that's the difference between a web player like Koel and a web controller for a server's player like MPD).

Implementing AURA api is a large work I'm not ready to do (I don't see the value yet).

@X-Ryl669 commented on GitHub (Feb 10, 2017): @Phyks If I understand correctly AURA is a REST api for Beets' music library organizer and player daemon. I don't see any client consuming AURA currently (except for a WIP dashboard web interface) and if there was one, it would except to send control command to a server to play some tracks, not to fetch and play the track locally on the client (that's the difference between a web player like Koel and a web controller for a server's player like MPD). Implementing AURA api is a large work I'm not ready to do (I don't see the value yet).

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@Phyks commented on GitHub (Feb 10, 2017):

This mix the other issue report a bit.

Indeed, this may deserve its own issue.

Currently, (except for songs), Koel works offline (once loaded, of course). This is not possible with pagination.

Sure, but although it may be useful for an app to build its local catalog, I'm not sure this is worth it for the web player, which may really suffer with large libraries (typically a few 10k songs). My point is that adding a /artists, /albums, /songs entry points with optional pagination and so on could help a lot the web interface (while keeping the data endpoint for bulk export).

Although Ampache API is really far from perfect, this is something I think is well done in their endpoints.

Implementing AURA api is a large work I'm not ready to do

Sorry, I did not mean implementing AURA as is. I was mostly pointing this out for the split of the misc methods.

@Phyks commented on GitHub (Feb 10, 2017): > This mix the other issue report a bit. Indeed, this may deserve its own issue. > Currently, (except for songs), Koel works offline (once loaded, of course). This is not possible with pagination. Sure, but although it may be useful for an app to build its local catalog, I'm not sure this is worth it for the web player, which may really suffer with large libraries (typically a few 10k songs). My point is that adding a `/artists`, `/albums`, `/songs` entry points with optional pagination and so on could help a lot the web interface (while keeping the `data` endpoint for bulk export). Although [Ampache API](https://github.com/ampache/ampache/wiki/XML-API#data-methods) is really far from perfect, this is something I think is well done in their endpoints. > Implementing AURA api is a large work I'm not ready to do Sorry, I did not mean implementing AURA as is. I was mostly pointing this out for the split of the misc methods.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@phanan commented on GitHub (Feb 11, 2017):

Very interesting ideas @X-Ryl669! Let me try to answer each of them below:

Separate songs from albums and albums from artists. Since song have the album_id and albums have the artist_id, there's no need they stay so intricated. This would also clean the messy JS code to split them back in their respective stores.

I've tried this before. Actually IIRC this is the first approach, and I've come to determine the current approach, a bit messier admittedly, has a great performance boost. Also, nesting this way actually reduces the data size (which is one of our main concerns here). Now, that doesn't in any way means I'm against exploring this idea (again) – as long as we can maintain and Koel's simplicity and swiftness, I'd be happy to consider.

Remove the created_at keys (it's a lot of useless information sent)

created_at wasn't there at the beginning, until we added the "Recently Added" stuff. Granted, Koel only uses 10 or so most recent songs/artists/albums, but we need to cater for other clients as well.

Use default value for missing fields (so instead of sending "image" : null for each artist), don't send the field. Same for boolean false (like is_compilation, only send if true)

We could totally do that if, again, the API was only consumed by Koel. For another client whose programming language is not JavaScript and is stricter in term of property checking, though, this can imply issues. So, as much as I think this is good for Koel itself, it can't be implemented I'm afraid.

Similarly for interactions, we could create 2 objects, one for liked = true and one for liked = false. This would limit to a list of "play_count" per song. In that case, it's probably even better to merge the interaction information back in the song object (so it avoid repeating the song id which is very large)
Last but not least, if keeping the interaction as-is, we could map an integer to each song (instead of such a large song id), we would save bytes. I think the idea above is better.

I don't really get this part. Could you elaborate?

Actually, as a huge fan of optimizing/refactoring myself (as you could have guessed if you've been following my commits), I don't think saving several bytes, or even KBs, is worth the effort. We only load the data once every, I don't know, week? Adding to that, a properly configured server should already be able to gzip the data beautifully and save us tons.

More long term, but split the data into multiple route, so it's possible to cache the data response (it does not change until you re-sync your media library). Only the interaction does change, so it would make more sense to have a separate route for it.

The data response is actually already being cached server-side by default, so I'd assume we're talking about client-side caching now. At the beginning of this project (yes, that long ago) I did try quite a few client caching methods – local storage, indexedDB, localForage (which is a wrapper around the other technologies essentially) etc. For one reason or another, none of this really worked, and I decided to put that aside to focus on more important features. In the near future, I'll come back to this.

@Phyks Yes, we can add the endpoints for flexibility, and it's very simple with Laravel. Koel's frontend itself won't be using them as of now, though.

@phanan commented on GitHub (Feb 11, 2017): Very interesting ideas @X-Ryl669! Let me try to answer each of them below: > Separate songs from albums and albums from artists. Since song have the album_id and albums have the artist_id, there's no need they stay so intricated. This would also clean the messy JS code to split them back in their respective stores. I've tried this before. Actually IIRC this is the first approach, and I've come to determine the current approach, a bit messier admittedly, has a great performance boost. Also, nesting this way actually _reduces_ the data size (which is one of our main concerns here). Now, that doesn't in any way means I'm against exploring this idea (again) – as long as we can maintain and Koel's simplicity and swiftness, I'd be happy to consider. > Remove the created_at keys (it's a lot of useless information sent) `created_at` wasn't there at the beginning, until we added the "Recently Added" stuff. Granted, Koel only uses 10 or so most recent songs/artists/albums, but we need to cater for other clients as well. > Use default value for missing fields (so instead of sending "image" : null for each artist), don't send the field. Same for boolean false (like is_compilation, only send if true) We could totally do that if, again, the API was only consumed by Koel. For another client whose programming language is not JavaScript and is stricter in term of property checking, though, this can imply issues. So, as much as I think this is good for Koel itself, it can't be implemented I'm afraid. > Similarly for interactions, we could create 2 objects, one for liked = true and one for liked = false. This would limit to a list of "play_count" per song. In that case, it's probably even better to merge the interaction information back in the song object (so it avoid repeating the song id which is very large) > Last but not least, if keeping the interaction as-is, we could map an integer to each song (instead of such a large song id), we would save bytes. I think the idea above is better. I don't really get this part. Could you elaborate? Actually, as a huge fan of optimizing/refactoring myself (as you could have guessed if you've been following my commits), I don't think saving several bytes, or even KBs, is worth the effort. We only load the data once every, I don't know, week? Adding to that, a properly configured server should already be able to gzip the data beautifully and save us tons. > More long term, but split the data into multiple route, so it's possible to cache the data response (it does not change until you re-sync your media library). Only the interaction does change, so it would make more sense to have a separate route for it. The data response is actually already being cached server-side by default, so I'd assume we're talking about client-side caching now. At the beginning of this project (yes, that long ago) I did try quite a few client caching methods – local storage, indexedDB, localForage (which is a wrapper around the other technologies essentially) etc. For one reason or another, none of this really worked, and I decided to put that aside to focus on more important features. In the near future, I'll come back to this. @Phyks Yes, we can add the endpoints for flexibility, and it's very simple with Laravel. Koel's frontend itself won't be using them as of now, though.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Feb 13, 2017):

Thanks for answering.

I don't really get this part. Could you elaborate?

Few ideas:

Basically, song ids are long string hash. We don't care about the hash in the client side, so it can be mapped to an integer server side (based on index ?), and only send integers instead => long work, small improvement, but improvement nonetheless. This helps reducing interactions too (and for me, folder's too).
Remove the created_at in songs
Currently, since I'm a shuffle maniac too, the interactions key is very large, almost all songs are listed. If we don't split the interactions key in its own route, then it might be useful to remove it completely and store the play_count in the song's object itself (in addition to the other's song key like album_id ...etc...).
If we do split the interactions in its own route, then make the object looks like:

   "interactions" : 
       { "liked": 
              [ { "song_id": 12, "play_count": 234 }, ... ], 
         "not_liked": 
              [ { "song_id": 567, "play_count": 5 }, ... ],
         "last_added_song_id": // Most recent first order
              [ 123, 124, 156, 167, 188, ... ]
       }

For one reason or another, none of this really worked, and I decided to put that aside to focus on more important features. In the near future, I'll come back to this.

I agree with this 100%. The ideas above are "nice to have", not required. I just spend some time brainstorming.

created_at wasn't there at the beginning, until we added the "Recently Added" stuff. Granted, Koel only uses 10 or so most recent songs/artists/albums, but we need to cater for other clients as well.

Ok. What are the other clients ? (I'd like to estimate the work required to change them or if it makes sense at all)

The data response is actually already being cached server-side by default, so I'd assume we're talking about client-side caching now.

For data caching I was more thinking about native caching of the HTTP session via a ETag (not javascript or fancy technology in fact). Basically, since the server already compute a cache, it can compute a ETag based on the data. Comparing would be done server side and returns 304 Unmodified if it's the same as the client's cache ETag. This only works if the data does not change.
Currently, each boot up of the interface create a new data (since the play count has likely changed inside the interactions part). So splitting interactions apart make caching actually useful, because the other data does not change.

While doing this, it might be useful to set a "Recently added song" key in the new request, removing the bunch of created_at data.

Anyway, it nice to know you've already tried this and that so I don't waste time re-inventing the wheel.

@X-Ryl669 commented on GitHub (Feb 13, 2017): Thanks for answering. > I don't really get this part. Could you elaborate? Few ideas: 1. Basically, song ids are long string hash. We don't care about the hash in the client side, so it can be mapped to an integer server side (based on index ?), and only send integers instead => long work, small improvement, but improvement nonetheless. This helps reducing `interactions` too (and for me, folder's too). 2. Remove the `created_at` in songs 3. Currently, since I'm a shuffle maniac too, the `interactions` key is very large, almost all songs are listed. If we don't split the `interactions` key in its own route, then it might be useful to remove it completely and store the `play_count` in the song's object itself (in addition to the other's song key like `album_id` ...etc...). 4. If we do split the `interactions` in its own route, then make the object looks like: ``` "interactions" : { "liked": [ { "song_id": 12, "play_count": 234 }, ... ], "not_liked": [ { "song_id": 567, "play_count": 5 }, ... ], "last_added_song_id": // Most recent first order [ 123, 124, 156, 167, 188, ... ] } ``` > For one reason or another, none of this really worked, and I decided to put that aside to focus on more important features. In the near future, I'll come back to this. I agree with this 100%. The ideas above are "nice to have", not required. I just spend some time brainstorming. > created_at wasn't there at the beginning, until we added the "Recently Added" stuff. Granted, Koel only uses 10 or so most recent songs/artists/albums, but we need to cater for other clients as well. Ok. What are the other clients ? (I'd like to estimate the work required to change them or if it makes sense at all) > The data response is actually already being cached server-side by default, so I'd assume we're talking about client-side caching now. For data caching I was more thinking about native caching of the HTTP session via a ETag (not javascript or fancy technology in fact). Basically, since the server already compute a cache, it can compute a ETag based on the data. Comparing would be done server side and returns **304 Unmodified** if it's the same as the client's cache ETag. This only works if the data does not change. Currently, each boot up of the interface create a new data (since the play count has *likely* changed inside the `interactions` part). So splitting `interactions` apart make caching actually useful, because the other data does not change. While doing this, it might be useful to set a "Recently added song" key in the new request, removing the bunch of `created_at` data. Anyway, it nice to know you've already tried this and that so I don't waste time re-inventing the wheel.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@0xcaff commented on GitHub (Nov 23, 2017):

It seems that there are two issues being discussed here:

Figuring out a way to document the API.
Desigining an API which provides rich data but is also performant.

Check out GraphQL. It allows you to define a schema (which can be documented easily) of all possible requests and responses and allows you to query (and compute) only the parts of the responses which are needed.

@0xcaff commented on GitHub (Nov 23, 2017): It seems that there are two issues being discussed here: 1. Figuring out a way to document the API. 2. Desigining an API which provides rich data but is also performant. Check out [GraphQL](http://graphql.org/). It allows you to define a schema (which can be documented easily) of all possible requests and responses and allows you to query (and compute) only the parts of the responses which are needed.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@0xcaff commented on GitHub (Nov 23, 2017):

Also, GraphQL clients like apollo-client make implementing caching easy.

@0xcaff commented on GitHub (Nov 23, 2017): Also, GraphQL clients like [apollo-client](https://www.apollographql.com/client/) make implementing caching easy.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@BrookeDot commented on GitHub (Apr 22, 2020):

Just noting that the documentation has moved to https://api-docs.koel.dev/ and we may be able to close this.

@BrookeDot commented on GitHub (Apr 22, 2020): Just noting that the documentation has moved to https://api-docs.koel.dev/ and we may be able to close this.

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@bilogic commented on GitHub (Jul 2, 2023):

I was able to get a jwt-token, but based on this https://api-docs.koel.dev/#play-a-song,
https://example.com/api/10/play?jwt-token=... responded with The route api/10/play could not be found.

How is the API supposed to play a track?

Does it act as a remote to control another instance?
Or does the API expect the caller to play the file themselves? (It's not clear what is the response of the play API)
I'm hoping to control/play Koel in my VSCode like https://marketplace.visualstudio.com/items?itemName=shyykoserhiy.vscode-spotify

@bilogic commented on GitHub (Jul 2, 2023): I was able to get a jwt-token, but based on this https://api-docs.koel.dev/#play-a-song, https://example.com/api/10/play?jwt-token=... responded with `The route api/10/play could not be found.` How is the API supposed to play a track? 1. Does it act as a remote to control another instance? 2. Or does the API expect the caller to play the file themselves? (It's not clear what is the response of the play API) 3. I'm hoping to control/play Koel in my VSCode like https://marketplace.visualstudio.com/items?itemName=shyykoserhiy.vscode-spotify

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@phanan commented on GitHub (Jul 2, 2023):

The API docs is unfortunately not up to date, as I’ve not been able to
manage some time for it. If you use the web client you can find the new
route(s) in the dev tools.

On Sun 2. Jul 2023 at 14:09 bilogic @.***> wrote:

I was able to get a jwt-token, but based on this
https://api-docs.koel.dev/#play-a-song,
https://example.com/api/10/play?jwt-token=... responded with The route
api/10/play could not be found.

How is the API supposed to play a track?

Does it act as a remote to control another instance?

Or does the API expect the caller to play the file themselves?
(It's not clear what is the response of the play API)

I'm hoping to control/play Koel in my VSCode like
https://marketplace.visualstudio.com/items?itemName=shyykoserhiy.vscode-spotify

—
Reply to this email directly, view it on GitHub
https://github.com/koel/koel/issues/535#issuecomment-1616624166, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5O3UQFAVB5R5PZDWJMKQTXOFQG5ANCNFSM4C7KV6MQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@phanan commented on GitHub (Jul 2, 2023): The API docs is unfortunately not up to date, as I’ve not been able to manage some time for it. If you use the web client you can find the new route(s) in the dev tools. On Sun 2. Jul 2023 at 14:09 bilogic ***@***.***> wrote: > I was able to get a jwt-token, but based on this > https://api-docs.koel.dev/#play-a-song, > https://example.com/api/10/play?jwt-token=... responded with The route > api/10/play could not be found. > > How is the API supposed to play a track? > > 1. Does it act as a remote to control another instance? > 2. Or does the API expect the caller to play the file themselves? > (It's not clear what is the response of the play API) > 3. I'm hoping to control/play Koel in my VSCode like > https://marketplace.visualstudio.com/items?itemName=shyykoserhiy.vscode-spotify > > — > Reply to this email directly, view it on GitHub > <https://github.com/koel/koel/issues/535#issuecomment-1616624166>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB5O3UQFAVB5R5PZDWJMKQTXOFQG5ANCNFSM4C7KV6MQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@bilogic commented on GitHub (Jul 2, 2023):

@phanan

Thanks, I located

curl -X POST "https://example.com/api/interaction/play" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer ..." \
    -d '{"song":"uuid......"}'

But running it from a separate CLI had no effect, I guess there is no remote control API?

@bilogic commented on GitHub (Jul 2, 2023): @phanan Thanks, I located ``` curl -X POST "https://example.com/api/interaction/play" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer ..." \ -d '{"song":"uuid......"}' ``` But running it from a separate CLI had no effect, I guess there is no remote control API?

kerem commented

2026-02-26 02:33:01 +03:00

Author

Owner

@bilogic commented on GitHub (Jul 2, 2023):

I found https://github.com/koel/koel/issues/1151

How does remote work? I have an instance of Koel playing, but /remote says No active Koel instance found. Rescan, and clicking on Rescan does not generate any HTTP requests nor console logs.

Let me know if I should continue here or elsewhere since it doesn't pertain to API exactly.

@bilogic commented on GitHub (Jul 2, 2023): I found https://github.com/koel/koel/issues/1151 How does remote work? I have an instance of Koel playing, but `/remote` says `No active Koel instance found. Rescan`, and clicking on `Rescan` does not generate any HTTP requests nor console logs. Let me know if I should continue here or elsewhere since it doesn't pertain to API exactly.

kerem commented

2026-02-26 02:33:02 +03:00

Author

Owner

@phanan commented on GitHub (Jul 2, 2023):

I think it’s best to open a new issue describing what you want to do. I’m
at loss as to what you’re trying to achieve here. Feel free to tag me.

On Sun 2. Jul 2023 at 15:50 bilogic @.***> wrote:

I found #1151 https://github.com/koel/koel/issues/1151

How does remote work? Let me know if I should continue here or elsewhere
since it doesn't pertain to API exactly.

—
Reply to this email directly, view it on GitHub
https://github.com/koel/koel/issues/535#issuecomment-1616670578, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5O3UR2FVFL7M4EZIYKQPDXOF4DXANCNFSM4C7KV6MQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@phanan commented on GitHub (Jul 2, 2023): I think it’s best to open a new issue describing what you want to do. I’m at loss as to what you’re trying to achieve here. Feel free to tag me. On Sun 2. Jul 2023 at 15:50 bilogic ***@***.***> wrote: > I found #1151 <https://github.com/koel/koel/issues/1151> > > How does remote work? Let me know if I should continue here or elsewhere > since it doesn't pertain to API exactly. > > — > Reply to this email directly, view it on GitHub > <https://github.com/koel/koel/issues/535#issuecomment-1616670578>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB5O3UR2FVFL7M4EZIYKQPDXOF4DXANCNFSM4C7KV6MQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

Rows
Columns

[GH-ISSUE #535] API documentation #380