Email automation - threading

[Tom_Beckenham]

I'm working with a client who has a seemingly simple requirement:

"Send an email using Airtable data, then later reply to that email to chase the recipient - ensuring that the reply is in the same thread as the original"

This is deceptively difficult to achieve from Airtable, and I wanted to ask the community if they've found a great solution.

Here's a breakdown of the the problem:

1. Replying - Email clients require the in-reply-to and references headers to contain the Message-Id of the email being replied to in addition to the subject being prefixed with "Re: "
2. Nothing returns the Message-Id - The built in Airtable and Gmail automation actions do not return the message id of the email just sent - nor do they allow you to set the in-reply-to or references headers when sending an email. I looked at Zapier, Make.com, Gumloop. I couldn't find an off the shelf solution that did both things
3. Gmail API requires Oauth - I looked at connecting directly to the Gmail API in an airtable automation. The problem is that to login to the user's Gmail account, I need to direct the user back to a public URL. I can't do that from an automation. I looked at doing outside of Airtable then including then storing the refresh token... but thought that would be messy. Still, it's a possible answer
4. Google Apps Scripts redirect - I then managed to get the whole thing working in a Google Apps Script attached to the user account. I got this working via cURL using GET (could not get a POST web app to return data with JSON). However, I then found that Google sends a redirect to a different server to return data. Airtable's implementation of fetch does not provide a way to follow redirects. It looks like there is no way to call a Google Apps script and get data back into Airtable. Am I wrong? I found a post outlining this problem. Thanks @Bill_French

I am considering two possible solutions:

1. API back to Airtable from the Google Apps Script - instead of trying to return data from Google Apps, I could instead have it write data into an Airtable record in the base. e.g. Fire off a POST http request to a Google App Script on the user's gmail account to send the email, then have the app script create a record in the Airtable base with the Message-Id of the email it just sent. I wonder if I'm going to run into issues with this considering that Airtable's implementation of fetch is blocking.
2. Create my own NextJS app to send the email - Instead of fiddling around with Google Apps, I could instead create a NextJS app that allows the user to login with Google to attach their account, then provides an custom API to send emails. I could design it to make it work with Airtable's implementation of fetch. It feels like overkill to go down this route.

Has anyone looked at this problem before? It would be great to hear what the community thinks of the proposed solutions. If you want any code examples, let me know

[Sachin_191]

Hey @Tom_Beckenham 

You've got a complex challenge on your hands, but both of your proposed solutions are heading in the right direction. Here's my take:

• Google Apps Script + Airtable API Backfeed: This is probably the most efficient route if you want to avoid overengineering. By sending the email via Google Apps Script and then writing the Message-Id back to Airtable as a record, you'll have everything you need for future replies. You could automate a fetch from the Airtable base after sending the email to ensure you capture the necessary data for the "In-Reply-To" header. This avoids fetch limitations and keeps it all within the same ecosystem.

• NextJS Custom API Solution: While this feels like overkill for the issue at hand, if you're envisioning scalability and future projects that may rely on more complex email automation or user management, this could be the longer-term robust solution. It would provide a custom layer to handle OAuth, replies, and threading without depending too much on Google or Airtable limitations.