Why Does Specifying More Than 21 Fields in n8n’s AirTable Node Trigger a 422 Error?

Based on the current documentation and our knowledge of the Airtable node, there isn’t an explicitly documented upper limit on the number of fields you can retrieve. However, the error you’re encountering—triggered when specifying more than 21 fields—is likely the result of how n8n (or the underlying Airtable API) validates the “fields” parameter. In other words, while the Airtable API itself may not document a hard cap, the node’s implementation appears to enforce one.

Here are a few workarounds you might consider within n8n:

1. Split the Request:
   Instead of fetching all desired fields in one call, break the query into two or more separate Airtable node calls. Each call retrieves a subset of fields, and you can then merge the results later in your workflow using nodes such as “Merge” or “Set.”

2. Avoid the Fields Parameter:
   When you leave the “fields” parameter unspecified, the node may return data based on the dedicated view’s configuration. If that view doesn’t yield all the required fields, consider updating the view in Airtable so it shows all the fields you need. That way you can avoid hitting the parameter validation restriction.

3. Use the HTTP Request Node:
   If splitting the request isn’t feasible, consider using the HTTP Request node to call the Airtable API directly. This allows you finer control over the request (including managing a larger “fields” array) but will require closely following the Airtable API documentation to format the request correctly.

Each of these approaches can be implemented entirely within n8n and may help you bypass the current limitation you’re facing with the Airtable Search Records function.

Remember that this limitation appears to be a side effect of how the integration is implemented rather than an inherent constraint in Airtable itself. You may also want to review any recent updates in the node’s documentation or community discussions if there has been any change regarding handling a large number of fields.

Does this provide the clarity you need to proceed?

It appears that the error arises not from n8n itself but from the way the Airtable API (and the underlying HTTP GET request) handles an extensive list of fields via query parameters. In other words, when you manually specify more than about 21 fields, the resulting URL (with many repeated field parameters) can exceed what Airtable’s API accepts (or violates its parameter validation rules).

Below are some workarounds you can consider:

1. Use a Dedicated View with Airtable

Airtable views let you limit which fields are returned. However, note that—even when using a dedicated view—the node may not return fields that the view hides. If you still need more than a certain number of fields and the view approach isn’t acceptable (because it suppresses some required fields), you may need an alternative method.

2. Use the HTTP Request Node Instead

By replicating the functionality of the Airtable Search Records function with the HTTP Request node, you can avoid hitting the GET query parameter limit. Airtable provides a “listRecords” POST endpoint that accepts your parameters as a JSON object in the body rather than as URL query parameters. This means you can include a long list of fields without running into URL or parameter validation issues.

For example, you could set up your HTTP Request node like this:

JSONCopied
{
  "method": "POST",
  "url": "https://api.airtable.com/v0/BASE_ID/TABLE_ID_OR_NAME/listRecords",
  "headers": {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json"
  },
  "body": {
    "fields": [
      "Field1",
      "Field2",
      // ... up to however many fields you need
      "Field22"
    ],
    "filterByFormula": "",
    "maxRecords": 100  // adjust as needed
  }
}

Replace BASE_ID, TABLE_ID_OR_NAME, and your API key with the correct details. This POST route avoids building an overly long query string.

3. Split the Request into Batches

If for some reason you still hit limits or need to perform a more complex query, consider splitting your request into smaller chunks (for example, processing fewer fields per request) and then merging the data within n8n. However, the POST approach is generally more straightforward for handling many fields.

---

Summary

There isn’t an explicit limit set by n8n on the number of output fields, but the issue is due to how the Airtable API validates the request when too many fields are supplied as query parameters on a GET request. Switching to the POST-based “listRecords” endpoint via the HTTP Request node is a recommended workaround that brings more flexibility and bypasses the limitations of the GET parameters.

By adapting one of these approaches, you should be able to retrieve all the required patient data fields without encountering the error.