Help

Re: Using the "fields" query parameter in Appgyver

Solved
Jump to Solution
2316 3
cancel
Showing results for 
Search instead for 
Did you mean: 
James_Burton
5 - Automation Enthusiast
5 - Automation Enthusiast

Hi… I am using Airtable as my backend for an app I am building in Appgyver. I am trying to experiment with Airtable’s query parameters and I just can’t seem to get some things to work. Currently, I am just trying to retrieve a list of records, but only certain fields for those records. The API Documentation for Airtable seems straightforward but I keep getting the same error:

Screen Shot 2022-10-25 at 9.50.42 PM

I received a response from a helpful Appgyver user who pointed out that “The HTTP 422 Unprocessable Entity Code indicates that the server has understood the type of query content and that the request syntax is correct but that the server has not been able to carry out the requested instructions.
You have to formulate your request differently to access your data.” However, he stopped short of explaining exactly what this means.

Any takers here able to help? Thank you!

1 Solution

Accepted Solutions
James_Burton
5 - Automation Enthusiast
5 - Automation Enthusiast

Thank you for this response! This is helpful and I think gets me close to figuring this out. There is still something though that’s not quite clear to me.

If you’re unfamiliar with Appgyver, the way it asks you to configure your data is by setting up the query parameters with the appropriate keys like this:

Screen Shot 2022-10-27 at 5.05.29 PM

Then when testing the data it asks for the extension of the query parameters in javascript here:

Screen Shot 2022-10-27 at 5.08.12 PM

What seems to work when using the “view” and “filterByFormula” parameters is assuming the key identifier and adding the rest of the formula, so in my example above view: “Master” turns into just “Master”. Are you following so far?

So the reason I included the syntax the way I did initially, is the javascript version of the Airtable API instructions looks like this:

Screen Shot 2022-10-27 at 5.15.07 PM

So… assuming the same logic, I cut out the fields: and just input [“ProjectName”, “ProjectID”].

But what you’re suggesting looks quite a bit different than this, and if it’s right it’s not clear to me how I turn that into javascript where the key is assumed as part of the configuration. Would the word “fields” be repeated for every field you request, and if so, why is it not structure that way in the javascript version of the API documentation?

Am I making any sense? So sorry if I’m using some of these terms incorrectly. I am still grasping at straws when it comes to a lot of the coding language and terminology.

I REALLY appreciate your help.

See Solution in Thread

5 Replies 5

The fields query parameter for Airtable REST API calls is a tricky one. The key thing to note is this example from the API docs and the note that follows it:

The %5B%5D combo is just a pair of square braces when unencoded, so essentially what the request needs (pre-encoding) is:

fields[]=fldnj6C3TO9Q4OkFU&fields[]=flduAEGnxXz4LN5B0

If you’re using field names instead of field IDs, the same would also apply.

Based on your screenshot, you’re passing the field names as a single array:

["ProjectName", "ProjectID"]

Following the guidelines outlined in the docs, the final query string (encoded) should look more like this:

fields%5B%5D=ProjectName&fields%5B%5D=ProjectID

In the end, you need to pass each field name separately, and with no quotes surrounding each name. I’m not familiar with Appgyver, so I’m not sure if it will allow you to include the fields%5B%5D path parameter property more than once, but that’s what Airtable’s API requires when specifying multiple fields.

James_Burton
5 - Automation Enthusiast
5 - Automation Enthusiast

Thank you for this response! This is helpful and I think gets me close to figuring this out. There is still something though that’s not quite clear to me.

If you’re unfamiliar with Appgyver, the way it asks you to configure your data is by setting up the query parameters with the appropriate keys like this:

Screen Shot 2022-10-27 at 5.05.29 PM

Then when testing the data it asks for the extension of the query parameters in javascript here:

Screen Shot 2022-10-27 at 5.08.12 PM

What seems to work when using the “view” and “filterByFormula” parameters is assuming the key identifier and adding the rest of the formula, so in my example above view: “Master” turns into just “Master”. Are you following so far?

So the reason I included the syntax the way I did initially, is the javascript version of the Airtable API instructions looks like this:

Screen Shot 2022-10-27 at 5.15.07 PM

So… assuming the same logic, I cut out the fields: and just input [“ProjectName”, “ProjectID”].

But what you’re suggesting looks quite a bit different than this, and if it’s right it’s not clear to me how I turn that into javascript where the key is assumed as part of the configuration. Would the word “fields” be repeated for every field you request, and if so, why is it not structure that way in the javascript version of the API documentation?

Am I making any sense? So sorry if I’m using some of these terms incorrectly. I am still grasping at straws when it comes to a lot of the coding language and terminology.

I REALLY appreciate your help.

Those JavaScript instructions are only applicable if you’re using the official JavaScript client, which requires that you be running in a Node.js environment. Because you’re not doing that, those instructions don’t apply in your situation.

Yes. That’s how the cURL documentation for the API is formatted in its examples, which was the basis for what I indicated above.

If you were writing out the full URL and all of its parameters manually (following the cURL guidelines in the API docs), it would be relatively easy. However, because of the way that Appgyver is making you spell out the parameters first and then add data for them, I’m not sure if there’s a way to tell it that you need to use the fields[] parameter multiple times. (It’s admittedly an uncommon way of using URL query parameters, but it’s been that way for so long that it would cause a lot of problems if Airtable were to redesign the API to accept multiple fields in a different way.)

In the second screenshot from your most recent post, I can see that you’re attempting to apply a workaround by including the square braces as part of the data, but this isn’t going to work. Under the hood, Appgyver is building a cURL-style HTTP call, so that technique isn’t going to create:

fields[]=ProjectName

Because it’s going to automatically insert an equals symbol between the fields parameter name and the provided data, it will end up creating this, which will lead to an error:

fields=[]=ProjectName

You might try adding the square braces in the definition of the key, and then pass only the field name in the Test stage, but that’s only going to let you request a single field unless it allows you to repeat the same key multiple times. My gut says that it won’t let that happen.

I almost recommended a workaround where you pass the other field names as part of the “value” assigned to a single fields[] key, but that wouldn’t work because it would encode things like the separating ampersand that need to remain unencoded for proper URL structure.

Barring Appgyver letting you add more than one iteration of the fields[] parameter, you could just skip that parameter and let it return all fields. It might affect performance depending on how many fields are in the table that you’re querying, but I’m not sure what else to suggest.

Thank you. This is very helpful. Here’s the update:

I took your suggestion and added the square braces in the definition of the key, and it worked! Alas, you were also correct that there doesn’t seem to be a way to configure multiple fields this way. I tried adding to field parameters; it actually let’s me add it but only one shows up in the test area.

I assume the same challenges would apply to the sort parameter? As I can’t seem to get that to work either and some of the cURL syntax looks the same.

Yup. Any parameter that’s allowed to be repeated will suffer the same fate with Appgyver’s configuration system. The only way around it is to build the full URL for the API call from scratch. You could try building the full URL that you want directly in the “Relative path” field in the Config tab, and then delete all of the query parameter settings so that the full path that you typed is exactly what’s used.