Unfortunately it’s a random order, so if you want them in a certain order, you will need to specify it yourself.

(I haven’t tested this, but I believe that the order is actually an alphabetical listing by Record ID, which is completely random.)

No Problem Thank you for clarifying I figured as much after testing but wasnt certain. Suppose this can be closed now.

@kuovonne I don’t deal in the REST API, but my understanding is that the order records are retrieved is typically by creation date. Do you happen to know if that’s the case?

I do not know the default sort order, and it is not documented. In any case, the default sort order is not the same as any order that is seen in the user interface (except by chance).

If you need records in a particular order, especially if you need 100 or fewer records, I highly recommend specifying a sort order.

Yeah, this is very bizarre — my assumption above about it sorting by Record ID was wrong. And yet it also doesn’t sort by Creation Date, either.

I just tested this on a very small sample of 5 records, and this is the order of Record ID’s that it returned:

rec2tZeyhfWhK5YT2


recnGShmnP4HUCVVy


recEaCKguCzhBtCYh


recsJukjkzONmEKqE


recLea8Kg9UkSLHsQ

And this is the order of creation dates that it returned:

2020-06-20T14:06:16.000Z


2020-12-17T20:05:53.000Z


2020-12-17T20:05:11.000Z


2020-12-17T20:06:01.000Z


2021-01-15T00:22:43.000Z

So it looks like it’s almost in alphabetical Record ID order (but it’s not), and it looks like it’s almost in creation date order (but it’s not).

So I think that the ordering must be truly random? We may want to reach out to Airtable Support to see if they know the answer to this, although the easy solution is to always specify our own sort order.

I’m not sure if @Adam_Minich is actively visiting the forums, but I’m going to tag him here to see if he has any insights on this.

I doubt that the order is truly random. Plus, if the end user actually needs a random record, I would not rely on the sort order being random. I also would not rely on the sort order being either the same or different across different calls. I prefer to think of the sort order as something more vague such as “indeterminate” or “unspecified”.

I think Scott is probably right. I just ran 10 tests with 7 records; each test used the same table but the data was entered the same after deleting the records. Random outcomes with every API request. This doesn’t mean they are reliably randomized but it does suggest if there is a pattern it is likely related to Airtable’s s storage layer and nothing specifically in the fields.

To be clear, with such a small sample size, we could predict some requests may return similar or identical orders. However, the law of large numbers tells us this would not be the case in most data sets. After further contemplation, my hunch is there is a pattern but it is likely related to how data at rest is actually recalled - perhaps a performance optimized algorithm deep inside Airtable.

I think we need a sandwich bet. :winking_face:

Count me in on the sandwich bet!! :sandwich:

Nor should you care. Here’s why… integrations should exist without the influence of users who may apply various sort order changes which would create a degree of brittleness at the integration layer.

If order is what you seek, allow Airtable’s server (or your server-side code) to do it. But above all, do not create dependencies that can be abruptly changed by anything external to the integration itself.

This is 100% true… although it would be nice to know what sort of internal algorithm Airtable is using for the default sorting of its records via the API. Is this where the sandwich bet comes in? :smiling_face_with_sunglasses: :sandwich:

That’s just it, there is no eapparent] sorting; it’s simply how they read the data from the storage layer. The algorithm likely has nothing to do with Airtable; more likely it has to do with the underlying database platform it all sits on and the recall performance requirements. They won’t reveal it because even they probably don’t know nor do they care to know.

My take - APIs (unless explicitly told otherwise) tend to hand you the data as fast as possible and that often means you get a tossed record salad.

You and I are on the “random” behavior. If there are others who believe it is not random, they need to bet against our horse. So far, I don’t see any takers. @Kamille_Parks?

Ah, yes, I see what you’re saying. That makes perfect sense.

Yes, this also makes 100% perfect sense, and this is exactly how it should be for the fastest speeds!

I’m hungry, people! Step up to the plate here!!

My bet is that the current default sort order used on Nov 3, 2021 will not be documented on the support website within my lifetime. Even if a default sort order is ever documented, it will not be clear if the default sort is retroactive back to this date. Unfortunately, it will be impossible for me to win this bet.

Oh no, count me out. I don’t even use the REST API lol

C’mon! You don’t have to use it to guess what it does. Triple or nothing bet?

@ScottWorld How would you guys force the sorting criteria when not using API. In my case, I am using an Airtable search formula in Zapier (something simple like AND({Description}="Hardware",{Amount}>="1000")) and I need the search results to be sorted via a specific column on my view...

How would one do that ?

@Nicolas_d_ANDRE 

I don’t use nor recommend Zapier anymore, because of TONS of limitations like this.

Make lets you search and sort records, and it’s all built natively into the product without needing to craft any custom API calls.

Make is significantly less expensive than Zapier, yet it is infinitely more powerful & customizable than Zapier.

There can be a bit of a learning curve with Make, which is why I created this basic navigation video for Make, along with providing the link to Make’s free training courses. There are also many Make experts hanging out there who can answer other Make questions. 

Thanks @ScottWorld - not the first time I am hearing that comment. I guess I'll give it a try. Start working on one workflow and if that's OK, start migrating...

@Nicolas_d_ANDRE You won't regret it!