My best guess is that listings are (lazily) loaded in parallel, so the order would be undefined. For practical purposes, that means that the list goes from listings with few offers to listings with lots of offers.
No idea if that’s how it really works.
Yup, we make a bunch of async requests for the data and simply assemble it in the order it returns.
Now, as for object-vs-array:
Shoving results onto the end of an array as we get them back is easy and lets you do nice things like check the length of the array to see how many items you got back. It also means you can use useful array functionality like (JS examples) .some(), .every(), .reduce(), etc w/o first having to jump through a bunch of hoops.
Constant-time lookups of a specific data ID doesn’t feel like a worthwhile trade-off for an API that is generally intended to provide bulk data, and if you did want that you could ask the API for data for the specific ID you cared about.
I’m open to sorting by ID once we have all the data back if you’d find it useful, I don’t think it would help programmatic usage much but does make the data nicer to look at.