Fields not returned as per View in API

[Ruchika_Abbi]

There are more fields being returned than in my View through the API.
Any suggestions on what could be the issue?

Regards,
Ruchika

[Bill_French]

Ruchika_Abbi:

There are more fields being returned than in my View through the API.

Please provide an example - screen shot of the fields in the API docs vs what’s actually displayed in an API result set.

[openside · Accepted solution]

@Ruchika_Abbi - the API doesn’t filter fields based on a view. It will filter records, but not fields. So, it will return all fields no matter the view you specify unless you tell it which fields you want returned via the fields parameter.

[Bill_French]

openside:

the API doesn’t filter fields based on a view.

I need to read more carefully. :winking_face: I now see what @Ruchika_Abbi meant.

Indeed, the API (like almost every API) returns all [populated] fields even when using a view ID despite the fact that the view itself may be designed to be more concise. As such, this is intentional, but one might ask - should it be intentional?

Perhaps any API queries based on a view should only return the fields marked visible to the view context.

It’s not obvious, but his would be bad; very bad.

• Imagine an API process that was built when View (x) had five fields. Now it has 11 fields, and 2 of the first five have been hidden. Calamity ensues.

• Imagine a certain view represents the most useful filtering of data for a given API process, but that API process must also use field values that were never intended for human consumption. API developers would find themselves in a cul-de-sac.

Conclusion: views, correctly expose all fields.

If you want to filter fields from result sets, you may do so with the “fields” parameter.

[Ruchika_Abbi]

Interesting. Thanks for the replies!
I just assumed since View was a parameter of the API all rules of the view will apply. In this case then, View is used for record filtering only and not field visibility.

[Bill_French]

Ruchika_Abbi:

View is used for record filtering only and not field visibility.

Correct. And, it is equally as brittle. An unsuspecting user with authority could change the filter, upsetting any API processes that depend on the view. As such, I encourage clients to name views in a manner that help to avoid API disruption.

This changes under the new proposed security features that Airtable should be releasing soon which I believe will make it easier to defend against arbitrary view tampering.