Thoughts on the /author/sales endpoint of the new API

A few months ago I made SalesRobot and it worked fine for most users and for a certain period of time. However the recent changes to the Statement and the API really started to hurt the app.

What I’m talking about is the addition to the Author Fees and now separate transaction for included support. It’s really impractical and unreliable to try to match 4 separate entries together and calculate the actual earning from a product sale with these changes.

I looked at the new API and more specifically at the /author/sales endpoint and for a moment I thought it was awesome, because it provided the total earnings per sale in a single entry, and it also included your entire history of sales. However, there is one huge problem with this endpoint, and the problem is that it returns every bit of information about the product sold in each entry, like the entire description of the item, compatible software, etc.

It’s literally 4 screens worth of information (13" laptop screen) of something that could have been just a product name, timestamp and amount. After all, the endpoint is called “sales”, and all that product information deserves it’s own endpoint.

These are just my thoughts on this, and I’m speaking strictly in the context of this app. I’m just frustrated with the API because it will hurt my app’s performance a lot. I would appreciate some feedback from other developers who solved this problem, or from Envato to tell us more about the idea behind this API endpoint.

rant over

Cheers

Yes it’s quite a bit of extra information. Having a flag in the API query to hide/show that particular information would be good

Especially for mobile apps where you don’t really want to be pulling down all that additional information.

That is exactly my concern. The app would take ages to load on a 3G network, and even on wifi on my laptop I can notice how much slower it is compared to loading the Statement endpoint.