Skip to main content

$api_key = ‘KEY GOES HERE]’;

$base_id = ‘appPrp2UDQKyeozka’; // Base ID for entire scorecard machine

$table_id = ‘tblhkGjHUAMbsLYDF’; // Table ID

$view_id = ‘viwnABjCLiL9eAiip’; // View ID

$scorecard_id = ‘recNQHVVwauXgaS3q’;

$url = ‘https://api.airtable.com/v0/’ . $base_id . ‘/’. $table_id . ‘/?view=’.$view_id; //’&fields%5B%5D=Criteria&fields%5B%5D=Section%20Link’;

$headers = array(

'Authorization: Bearer ’ . $api_key

);

$ch = curl_init();

curl_setopt($ch, CURLOPT_HTTPGET, 1);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_TIMEOUT, 10);

curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

curl_setopt($ch, CURLOPT_URL, $url);

$entries = curl_exec($ch);

curl_close($ch);

$airtable_response = json_decode($entries, TRUE);


This gives me a response with the items in this view. But they aren’t ordered by the order in the view? How can i fix this?

Hi Alchemy, and welcome to the community!



Views do not determine the format or order of API results; if they did, it would be a very brittle design and easy to break by unsuspecting users.


Two ways to do this -




  1. Sort the results from the API call when you get them - in javascript it’s fast, it’s easy, and it’s a common success pattern.




  2. Use the sort parameter of the API itself.




Hi Alchemy, and welcome to the community!



Views do not determine the format or order of API results; if they did, it would be a very brittle design and easy to break by unsuspecting users.


Two ways to do this -




  1. Sort the results from the API call when you get them - in javascript it’s fast, it’s easy, and it’s a common success pattern.




  2. Use the sort parameter of the API itself.






…which is bizarre, because they do return the view’s record order when using Airtable’s internal APIs (scripting apps and automation script actions). No idea why this isn’t consistent behavior.


…which is bizarre, because they do return the view’s record order when using Airtable’s internal APIs (scripting apps and automation script actions). No idea why this isn’t consistent behavior.



Yeah - it’s a mystery for sure. Any automated process that has a sort dependency based on a view is a red flag for me and it should be a warning for every script/automation developer. Views should be treated simply as pre-filtered containers and even then, it’s a roll of the dice because filters are easily modified without any consideration of app dependencies.


API-based processes should never be dependent on configurations easily changed by everyone. It’s the definition of code brittleness.


The REST API documentation says that the records in the view should be sorted according to the view. However, if the view also contains grouping, the results may not be grouped, which will give a different record order.



If the records returned are not sorted per the view, but are filtered by the view, and the view has no groupings, that’s a support ticket to open.



I think the original poster is writing in PHP, not JavaScript. PHP also has support for sorting arrays, though.



Lol. And so agrees everyone who has had an automation send off hundreds of emails in error when someone changes the filtering of an Airtable view.


The REST API documentation says that the records in the view should be sorted according to the view. However, if the view also contains grouping, the results may not be grouped, which will give a different record order.



If the records returned are not sorted per the view, but are filtered by the view, and the view has no groupings, that’s a support ticket to open.



I think the original poster is writing in PHP, not JavaScript. PHP also has support for sorting arrays, though.



Lol. And so agrees everyone who has had an automation send off hundreds of emails in error when someone changes the filtering of an Airtable view.



Synced tables will also adhere to filters easily changed by anyone. For the receiving table it’s the equivalent of deleting those records. Hence, every recored linked to that synced table will lose that reference with no CMD+Z to the rescue.

At least you can lock a view…


Synced tables will also adhere to filters easily changed by anyone. For the receiving table it’s the equivalent of deleting those records. Hence, every recored linked to that synced table will lose that reference with no CMD+Z to the rescue.

At least you can lock a view…



Indeed, with view locking and the recent ability to retrieve single records in script automations, there are ways to mitigate these challenges. However, architecturally speaking, there is no valid reason to to lean on user-defined features to act as an API “veneer”. Doing so fundamentally finances additional code debt.


Indeed, with view locking and the recent ability to retrieve single records in script automations, there are ways to mitigate these challenges. However, architecturally speaking, there is no valid reason to to lean on user-defined features to act as an API “veneer”. Doing so fundamentally finances additional code debt.


I agree. If you can do it in code, do it in code. It’s also more fun that way. 😄

Reply


Terms & Conditions