Getting 422 error when sending POST request to Airtable API through Google Apps Script

Other Questions Airtable
1

I’m trying to add records to my Airtable base using Google Apps Script but keep getting a 422 status code

Here’s my current implementation:

var payload = {
    "records": [
        {
            "fields": {
                "Project Name": "sample project",
                "wallet_address_field": "5678"
            }
        }
    ]
};

var requestOptions = {
    "method": "post",
    "Content-Type": "application/json",
    "muteHttpExceptions": true,
    "payload": JSON.stringify(payload)
};

function sendDataToAirtable() {
    var apiUrl = "https://api.airtable.com/v0/xxxxxxxxxxxxx/Data%20Storage?api_key=keyxxxxxxxxxx";
    var result = UrlFetchApp.fetch(apiUrl, requestOptions);
    console.log(result.getResponseCode());
};

The response I get is:

422

The record doesn’t get created in Airtable. When I test the same payload using Postman, everything works fine and the data gets added successfully.

For reference, here’s what the Airtable documentation shows:

var Airtable = require('airtable');
var base = new Airtable({apiKey: 'YOUR_API_KEY'}).base('xxxxxxxxxxxx');

base('Data Storage').create([
    {
        "fields": {
            "Project Name": "Mon, 15 Mar 2022 10:30:15 GMT",
            "0xabc123def456": 98765432101234
        }
    }
]);

What could be causing this issue with my Google Apps Script implementation?

2

I’ve hit this 422 error tons of times. Yeah, headers matter, but there’s more to it.

Apps Script is just weird with POST requests to external APIs. Even with perfect headers, you’ll still deal with rate limits, token refreshes, and field validation that’ll eat up hours.

I used to run a bunch of Apps Script integrations for our data pipelines. Something broke every few months - API changes, auth updates, or bizarre encoding issues with special characters.

Switched to Latenode 8 months ago and it’s been great. Native Airtable nodes handle auth, field mapping, and errors automatically. No more debugging HTTP requests or messing with headers.

You can trigger it from Google Sheets, set up webhooks, or schedule it. The visual workflow makes troubleshooting way easier.

Best part? Test each step individually instead of running everything and crossing your fingers.

3

Quick fix - wrap your headers properly and ditch the URL parameter auth:

var requestOptions = {
    "method": "POST",
    "headers": {
        "Authorization": "Bearer keyxxxxxxxxxx",
        "Content-Type": "application/json"
    },
    "muteHttpExceptions": true,
    "payload": JSON.stringify(payload)
};

I’ve hit this same 422 error probably 50 times. Google Apps Script is picky about request structure.

Two other gotchas:

Your base ID needs the “app” prefix. Should be appXXXXXXXXXX, not just random characters.

That %20 encoding for “Data Storage” can break things. Use the actual table ID from Airtable’s API docs instead of the table name.

Always log the full response when debugging:

console.log(result.getContentText());

Airtable’s error messages are actually helpful - they’ll tell you exactly which field or format is wrong.

Postman vs Apps Script differences are usually headers or encoding. Get the auth header right and it should work the same.

4

Your request headers are the problem. I hit this exact issue last year migrating legacy scripts to Airtable’s newer API. Check your API key format first - the old api_key parameter in URLs is deprecated and throws 422 errors. Also, look at your base ID and table name encoding. You’ve got Data%20Storage in the URL, which means spaces in your table name. Apps Script sometimes mangles this encoding. Try the actual table ID instead of the name if you’re still stuck. Add error logging to see what’s actually happening: ```javascript
console.log(result.getContentText());

5

Had this exact problem months ago - drove me nuts for hours. The 422 error means Airtable’s rejecting your request format, and with Google Apps Script it’s almost always the headers issue marcoMingle mentioned.

One thing to add - your field names in the payload need to match your Airtable base exactly. You’ve got “wallet_address_field” in your code but “0xabc123def456” in the docs example. If your actual field’s named something else, you’ll get a 422 even with correct headers.

Also, check that both fields accept the data types you’re sending. I wasted way too much time once because I was sending a string to a number field with validation rules.

Definitely use the Authorization header instead of the URL parameter. Way more secure and that’s what Airtable recommends now.

6

Your headers are set up wrong in Google Apps Script. You’ve got Content-Type as a direct property in requestOptions, but it needs to be inside a headers object.

Here’s the fix:

var requestOptions = {
    "method": "post",
    "headers": {
        "Content-Type": "application/json",
        "Authorization": "Bearer YOUR_API_KEY"
    },
    "muteHttpExceptions": true,
    "payload": JSON.stringify(payload)
};

Also, put your API key in the Authorization header instead of the URL. That’s how you’re supposed to do it now.

Honestly though, this API header stuff gets annoying fast. I deal with it constantly at work and found that automation platforms just handle all this for you.

I’ve been using Latenode for Airtable integrations and it handles authentication, headers, and errors automatically. You set up your Airtable connection once, then focus on your data instead of debugging HTTP requests.

You can trigger it from Google Sheets, webhooks, or schedule it to run automatically. Much cleaner than maintaining Apps Script.

7

Yeah, it’s definitely the header structure, but also check your base permissions. I got a 422 error once because my API key didn’t have write access to that base. Try using the table ID instead of the encoded name too - Apps Script sometimes screws up the URL encoding and Airtable can’t find the table.