Content API - Sort

Hello, Builder IO Team,

I need assistance with something related to sorting with content builder io API.

Context:
Well I have two custom fields in the data model:

  1. lastUpdatedDate
  2. date

Both are manually set from Visual editor and located inside data.
So a sort query by the custom date field looks like this
...&sort.data.date...
or sort by lastUpdatedDate like this
...&sort.data.lastUpdatedDate...

And sorting by one of these two returns the correct results and works perfectly, however, when i try to sort by lastUpdatedDate AND date things get messy and the response is not the expected one.

What i am trying to achieve:
In short i want to sort by lastUpdatedDate AND date simultaneously - something like this &sort.data.lastUpdatedDate=1&sort.data.date=1

using the date as a fallback as the lastUpdatedDate field may or may not be set intentionally.

As a solution I could get all the data for a model and then perform the sorting on the frontend, but i really don’t want to do that. That is why i am hoping that the described above is somehow possible?

1 Like

Hello @Mehan,

Thanks for raising this, you’re not doing anything wrong here.

Just to clarify, Builder’s Content API sort parameter doesn’t currently support true multi-field sorting via the query string. So even if you pass multiple sort params, it won’t behave like a compound sort. In most cases, only one of the fields actually gets applied, which is why the results can feel inconsistent.

The most reliable approach here is to introduce a single field, something like sortDate or effectiveDate. You can populate it with lastUpdatedDate when that’s available, and fall back to date otherwise. Then your query just sorts on that one field, which keeps things predictable.

If you don’t want editors to manage that manually, you can automate it using a webhook on publish and update the value via the Write API. That way it stays in sync without any extra effort.

Another option is to handle the sorting in your backend before sending the data to the client. That works well for most use cases, especially if the dataset isn’t too large.

Overall, this is a limitation of the API rather than an issue with your setup. Using a computed field tends to be the cleanest long-term solution.