You can browse through the site with the developer tools open in order to find API URLs.
I did this and spent a few hundred hours developing tools for NeonMob. I have to say the API is pretty bad.
Here are a number of bad API designs:
There are multiple different URL styles (napi.neonmob.com/[page] and neonmob.com/api/[page] and rarely just neonmob.com/[page])
There are two different output styles (JSON and the human readable Django REST framework) that are used by different endpoints. Although if the API is used by a website, you almost always get JSON automatically.
a. One endpoint randomly shows either JSON or Django REST framework, which caused my tool to break sometimes before I saw it and added ?format=json to the end of the URL which is normally never required because Django REST framework normally knows whether you use the browser or a website.
The output is often straightforward, but sometimes uses a very weird structure with deferreds (always empty), payload and refs where they link to a reference in an array, which you must then select instead of just putting the data directly in the array. It sometimes makes the size of the page smaller, but not always.
One endpoint works with old sets, but not with new sets.
Here are a few examples where data is missing/overwritten, which means you need to use the API often to prevent missing data:
Activities in the activityfeed overwrite older activities of the same day and there is no way to get them back if you haven’t stored the URL before it’s overwritten.
Activities have relative timestamps.
a. Trades have absolute timestamps in their own endpoint.
b. There is a way to get the absolute timestamp of the LAST opened pack of a set. I found this endpoint too late, so I already made a complex system to narrow down the relative timestamps, which I should now remove.
Opened packs don’t show the print numbers and you can’t see if cards are duplicate or the amount of prints you got in a pack.
a. New sets have auto incremented print ids, so the highest ids are the newest prints.
b. You should store all prints and compare which ones are new for old sets because their print ids are not auto incremented. Every card of an old set has a range of print ids with a corresponding print number. Although a print with a print number that’s 100 higher does not have a print id that’s 100 higher somehow, so it’s a little vague.
I will post the actual endpoints tomorrow when I have time.