I’m working on a WhatsApp chatbot project using Twilio Studio and need help storing user responses in a database.
I want to capture information that users provide during conversations and save it to an Airtable database. I found a tutorial online but the serverless function code doesn’t seem to work properly.
Here’s my current implementation:
exports.handler = function(context, event, callback) {
let userInfo = {
fullName: event.fullName,
userEmail: event.userEmail,
timestamp: Date.now()
};
var Airtable = require('airtable');
var database = new Airtable({apiKey: context.AIRTABLE_KEY}).base('appXYZ123ABC456DEF');
database('Contacts').create(userInfo, function(error, newRecord) {
if (error) {
console.error(error);
return;
}
console.log(newRecord.getId());
callback(null, userInfo);
});
};
When I test this with Postman, I get errors in the Twilio console and the function doesn’t execute successfully. The response shows issues but I can’t figure out what’s wrong.
I’m also wondering if I should use the HTTP Request widget in Twilio Studio Flow instead, but I’m not sure how to set it up correctly. My Airtable has these fields: ID, fullName, userEmail, and timestamp.
Can anyone help me identify what might be causing this problem?
Your function’s missing error handling in the callback. When something breaks, you’re not calling the callback at all - that leaves Twilio hanging.
Hit this exact problem last year with a support bot. Here’s the fix:
if (error) {
console.error(error);
callback(error, null);
return;
}
Check your Airtable base ID too. “appXYZ123ABC456DEF” looks like a placeholder. Grab the real one from your Airtable URL.
Your timestamp field might break things. Airtable’s picky about date formats. Try new Date().toISOString() instead of Date.now().
For the HTTP Request widget - yeah, I switched to that after fighting similar Twilio function issues. Just build a simple Express endpoint for the Airtable stuff, then call it from Studio. Way easier to test and debug.
Test locally with Twilio CLI first. You’ll save tons of deployment time.
Hit this same issue building a customer service bot. It’s probably your Airtable permissions plus the callback problems others mentioned. Fix the callback first, then make sure your API key has write access - not just read. I wasted hours before realizing mine was read-only. Also check that your userInfo field names match your Airtable columns exactly. Case matters. Your Date.now() creates a Unix timestamp, but Airtable wants ISO format for dates. Check Twilio console for specific error codes - they usually tell you exactly what’s wrong. The HTTP Request widget is way better long-term since you can add retries and complex logic without hitting Twilio’s function limits.
double-check your airtable base id first - that’s usually what’s wrong. your function isn’t resolving when it hits errors, which breaks twilio’s execution. wrap everything in try-catch and make sure you’re calling the callback. i’ve dealt with the same integration pain before.
Had the same issue with Twilio functions and databases. Your problem is the callback handling when errors happen. When Airtable fails, your function never calls the callback - Twilio just hangs there waiting, which causes those console errors. Fix it by using callback(error, null); instead of just returning. Also check your environment variables in the Twilio console. Make sure AIRTABLE_KEY is set right and has proper permissions. The HTTP Request widget approach? Actually more reliable. You get better control over error handling and timeouts. You’d create a separate endpoint for Airtable operations and call it from Studio. I prefer this method - cleaner separation and way easier to debug when stuff breaks.