Currently, the only criteria that can be used for /usr/xxx/listens are timestamps. A count can be specified, but there is no built-in paging support to allow getting the next set.

If a listen's timestamp was guaranteed to be unique for a user, this would not be a big problem; you just query again, using the last retrieved timestamp as a parameter.

However, timestamps are not guaranteed to be unique (duplicates from imports, or having multiple players submitting listens at once). That makes it trickier to deal with (requiring the client code to also look at whatever fields make up a unique ID, which I'm not sure is even explicitly documented).

As such, it would be useful to have paging available on those requests, e.g. /1/user/Foo/listens?min_ts=1234567890&count=13&page=5. It would also be good to explicitly document the primary key for listens as part of the API documentation.