Make.com/Airtable webhook

[Schmidt127]

Hello,

I am looking for some help on an automation I am trying to run.  I am trying to use a make.com webhook with airtable so that when a new record shows up in airtable it sends the webhook to make.com.  I have the script that I am using and the connection and everything works but the webhook does not send the correct bundle of information.  It sends the record ID and then just generic information like 'header 'recipient', etc.  I am a school teacher and not a coder so I have been trying to get Chatgpt to help me with the script and I feel I am really close but don't know the scripting language enough to diagnose the problem.  Any help would be appreciated.

let table = base.getTable("Injury Report Form");

let recordId = input.config().recordId;

// Fetch the specific record

let record = await table.selectRecordAsync(recordId);

// Check if the record is fetched properly

if (record) {

    // Prepare the data to be sent to the webhook

    let data = {

        "recordId": record.id,

        "fields": {}

    };

    // Iterate through each field and add to the data object

    table.fields.forEach(field => {

        data.fields[field.name] = record.getCellValue(field.name);

    });

    // Webhook URL

    let webhookUrl = "https://hook.us1.make.com/mywebhook";

    // Send POST request

    await fetch(webhookUrl, {

        method: "POST",

        headers: {

            "Content-Type": "application/json"

        },

        body: JSON.stringify(data)

    });

}

Thank you Mike

[TheTimeSavingCo]

Hmm, I tried running your code and this was the webhook result, which looks good! 

Could you try logging your "data" object to see what's in it before it's sent?  i.e.

    table.fields.forEach(field => {
        data.fields[field.name] = record.getCellValue(field.name);
    });
    console.log(data)

[Collabability]

Easiest way is after the webhook sends over the record ID you probably need to use the "Get Record" module to fetch the rest of the data for that record.

But I think you need to fill in the "fields": {} array with the field names of the data you want to retrieve.

[ScottWorld]

@Schmidt127 

As @Collabability mentioned above, you don’t need that long script.

You just need a short & simple script that only sends the Record ID to Make’s webhooks.

I have written up full instructions on how to do this at this link.

– ScottWorld, Expert Airtable Consultant

[ScottWorld]

Also, in addition to what I wrote above, remember that you can’t use the trigger “when a new record is created” unless your data is coming from OUTSIDE an Airtable data entry screen  — such as coming from a form or coming from an API integration. You said in your original post “when a new record shows up in airtable”, so I’m assuming that your records are coming in from somewhere else, which would work fine. 

— ScottWorld, Expert Airtable Consultant

[TheTimeSavingCo]

@Collabability 
Yeap, `fields` is automatically populated here by the script when I ran it, and sends the cell values over to Make.  Did it work differently for you? 

Using a "Get record" module with the record ID definitely works, but we’d then need to keep an eye on any changes to field names in Airtable and update them in Make as necessary.  One workaround is to use the "Use column ID" setting to avoid issues, but in my experience subsequent modules end up using the IDs instead of the names which makes things hard to maintain as it just shows "fldUCR1V4ItIQAGm6" or whatever instead of "Name"

Since the script is already working, I feel like it'd be easier to just investigate what’s happening with the current workflow, you know what I mean?  That way all the data flows into Make via the webhook and we can just grab it from there without having to maintain or use an additional module / op

---
@Schmidt127if you end up wanting to just use the record ID instead, you don't need to make any changes to your workflow or script.  You're already sending the record ID over to Make as it is

If you'd really like to clean it up, you could just get rid of this bit:

// Iterate through each field and add to the data object
    table.fields.forEach(field => {
        data.fields[field.name] = record.getCellValue(field.name);
    });

And the line `"fields:{}"` here:

   let data = {
        "recordId": record.id,
        "fields": {}
    };

Those are the lines that help you consolidate your record's data to push into Make, and so once you remove them you'll only be sending the record ID over, and you'd use that record ID in a "Get Record" module

[ScottWorld]

@TheTimeSavingCo Your comment about the field name changes makes no sense, because the exact same problem would happen if you use a script.

Make’s “Get A Record” module will always return the most up-to-date field names. If future modules refer to an outdated field name, then they won’t work properly.

The exact same thing would happen with a script. if you send the most recent field names from a script to Make, but future modules are referring to the old field names, then they won’t work properly.

There is no advantage to using the script.

The easiest way to do all of this is to follow my technique of just sending the Record ID to Make, and have it pull in the current information.

Also, most importantly, the rule of thumb is to not change field names that are used in 3rd-party apps, because of dependency issues like this.

[TheTimeSavingCo]

@ScottWorld.  Interesting!  What's the advantage of having the additonal "Get a record" module instead of pushing it all in if they're both facing the field names issue?  Bearing in mind that the script already works and is pushing in all the data, and we'd have to set up a new "Get a record" module and use an additional op per run here

[ScottWorld]

It’s always fine to use any technique that works correctly, but simplicity & less coding is always the path that I like to follow.

When you just send the Record ID, the script is significantly simpler and you can manage everything in a no-code way over at Make.

Also, I’m not sure how the more complex script handles different field types like simple arrays and complex arrays, but Make already recognizes the various Airtable field types without needing to account for them in the script.

As long as a method works, it should be fine, but I always steer for simplicity and no-code. 

[TheTimeSavingCo]

Thanks for clarifying your approach!  Simplicity is always a solid choice.  We might just have different perspectives on simplicity here as not needing to create a new module seems simpler to me in this situation!