Enforcement of URL length limit for Web API requests
  • 03 Dec 2022
  • 2 Minutes to read
  • Dark
    Light
  • PDF

Enforcement of URL length limit for Web API requests

  • Dark
    Light
  • PDF

Article Summary

Requests to the Web API are subject to a 16,000-character limit for the URL length. Requests that exceed this limit typically have a workflow that involves complex formulas and filtering that greatly increases the URL length when these are passed as query parameters. This article covers the necessary details and alternative workarounds if your workflow does in fact exceed this limit.


Alternatives

If you have a workflow that would otherwise require requests to exceed 16,000 characters, you can use one of the following alternatives:

Use POST instead of GET

We have created a new POST version of the existing GET list table records endpoint which will allow you to pass the same options you may currently be using through query parameters as JSON in the request body instead. This will greatly reduce the overall URL length since these parameters will no longer need to be included in the URL.

GET endpoint: https://api.airtable.com/v0/BASE_ID/TABLE_ID_OR_NAME

POST endpoint: https://api.airtable.com/v0/BASE_ID/TABLE_ID_OR_NAME/listRecords

Note
The key to this change is the use of listRecords at the end of the URL.

For example, here is how a GET request for retrieving table records that includes multiple query parameters might look today:

curl 
https://api.airtable.com/v0/BASE_ID/TABLE_ID_OR_NAME?cellFormat=string&fields%5B%5D=Field1&fields%5B%5D=Field2&maxRecords=50&pageSize=10&filterByFormula=%7BDays%20overdue%7D%20%3E%203 \
  -H "Authorization: Bearer YOUR_API_KEY"

Following the addition of a new POST route, this same request would be made like this where the query parameters are now part of the request body:

curl -X POST https://api.airtable.com/v0/BASE_ID/TABLE_ID_OR_NAME/listRecords \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
  "cellFormat": "string",
  "fields": ["Field1", "Field2"]
  "maxRecords": 50,
  "pageSize": 10,
  "filterByFormula": "{Days overdue} > 3"
}'
Note

If you intend to use the timeZone and userLocale parameters, you will need to include these as query parameters, even with the POST version of the request:

curl -X POST https://api.airtable.com/v0/BASE_ID/TABLE_ID_OR_NAME/listRecords?timeZone=Europe%2FLondon&userLocale=en-gb  \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
  "cellFormat": "string",
  "fields": ["Field1", "Field2"]
  "maxRecords": 50,
  "pageSize": 10,
  "filterByFormula": "{Days overdue} > 3"
}'
Use a Filtered View

You can continue to make the same GET request for listing table records by creating a separate view of the same table with all the filtering you would normally pass using query parameters. From there, instead of including filterByFormula, you can pass the view ID with the request and the same results will be returned:

curl https://api.airtable.com/v0/BASE_ID/TABLE_ID_OR_NAME?view=Grid%20view \
  -H "Authorization: Bearer YOUR_API_KEY"
Note

In rare cases where you cannot resolve this with a view, we recommend using the first option of using the POST endpoint.

Using Airtable.js

If your workflow involves making requests using Airtable.js, we have already made a change to address this with the latest version of the SDK. In order to take advantage of this, you will just need to update the version you are using to 0.11.5 or higher.



Was this article helpful?