AppsScriptPulse

Tag: Medium

IntermediateSolutionsWeb App

Scale a 3,000-user web app on Google Apps Script and Google Sheets

Tags: ,
| | 0 Comments |

I built a web application used by more than 3,000 people. The backend was Google Apps Script. It ran for almost two years while we kept improving the application. We eventually moved it to AWS — not because Apps Script couldn’t handle the application, but because changes around Google’s authentication model gave us the opportunity to move to a more conventional backend and database architecture. Here’s how I built it, what problems we ran into, and why we didn’t build a traditional backend from the beginning.

In Pulse we’ve featured a couple of examples and tips on scaling Apps Script Web Apps. One of the most extensive solutions we’ve shared is Zig Mandel’s open-source Apps Script Website Integration Framework. Partha Sahoo has recently shared how his team used Google Sheets and Google Apps Script to develop a client facing frontend for over 3,000 users. The model they adopted is one I’ve not seen before. It’s a clever distributed model which combines a central database and script library with individual Google Sheets and Web Apps for each client. With this model workloads are shared across individual web apps:

There are some clever features in this solution which you can get an overview of in Partha’s post. A couple I would like to highlight are:

  • Exponential Backoff Polling: To stay comfortably below Apps Script’s quotas, the frontend avoided aggressive continuous polling. The client would initially poll every 5 minutes and if there were no changes to the data scaled down via exponential backoff to 30 minutes.
  • Central Library Multi-Tenancy: To avoid the burden of maintaining hundreds of individual web app deployments, core business logic lives in a versioned central Apps Script library (paired with a staging library for testing). This allowed Sahoo to ship bug fixes and feature rollouts fleet-wide instantly without redeploying individual client projects.

After nearly two years in production, the platform migrated to AWS. As Partha explains, the move was not driven by Apps Script reaching an operational bottleneck, but by evolving Google Workspace authentication policies, which made a conventional cloud backend more practical for long-term compliance. As noted in Partha’s post, the migration of the Apps Script code to AWS was easily refactored with AI assistance.

We’re in interesting times. On the one hand the beta Gemini side panel in the Apps Script Editor makes it easy to deploy web apps, on the other tools like Google AI Studio make it easy to vibe code applications to run in Google’s cloud infrastructure. Both introduce new risks, but also opportunities.

Source: How I Built a 3,000-User Web Application With Google Apps Script | by Partha S Sahoo | Sep, 2026 | Medium

New IDENo Code

Gemini in the Apps Script IDE: 8 Practical Developer Workflows by Stéphane Giron

Tags: ,
| | 0 Comments |

Summer 2026 has been huge for Google Apps Script developers, marked by two major milestones. First, Apps Script officially graduated to a Google Workspace Core Service … Second, Gemini is now natively integrated into the Apps Script IDE side panel. No more juggling browser tabs, context-switching to Google AI Studio, or copy-pasting prompts back and forth. To help you take full advantage of this workflow upgrade, here are 8 things you can do with Gemini directly inside Apps Script.

In August we highlighted the news Google Apps Script Editor: Gemini Side Panel Rolling Out!. This is a major feature update and as part of the beta you can read the latest information on Google’s Use the Gemini side panel in the Apps Script editor support page. A couple of requirements to headline.

Consumer accounts

  1. You have Google AI Pro / Ultra subscription
  2. Your account language is set to English

Google Workspace account

  1. The account has a Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Workspace Gemini Add-on, or Google AI Pro for Education licence
  2. Your account has been included in the Gemini Beta program by your admin
  3. Your account language is set to English

If you do have access to this feature then Stéphane Giron highlights 8 quick tips for getting started with Gemini in the side panel. These include:

  • Full project scaffolding & modification: Prompting Gemini to create multi-file architectures from scratch (such as generating paired .gs script logic and EmailTemplate.html templates).
  • Modernizing legacy code: Refactoring large script projects into clean, modular files with improved helper functions and error handling.
  • Language translation & unit tests: Converting legacy VBA macros automations directly into Apps Script, as well as creating automated unit tests.
  • One-click log debugging: A standout feature – clicking a button directly within execution logs to have Gemini diagnose and propose fixes for errors on the spot.

Follow the source link to explore Stéphane’s full walkthrough and visual breakdown of each prompt in action.

Source: Google Apps Script just got Gemini: 8 practical ways to use it in IDE — Stéphane Giron

DriveSolutions

Bypassing Google Apps Script Limits: A Zero-Cost Pipeline for Large Datasets

Tags: ,
| | 0 Comments |

Google Apps Script is easily my favorite runtime, so much so that I wrote a book about it. Yet, being a low-code environment it comes with its quirks, quotas and limitations. In a recent project I needed to process 300 spreadsheets totalling over 5 million cells in over 80,000 rows. I could eithr abandon the platform and spin up a “real” backend, or get creative. Really creative.

Dmitry Kostyuk has published a detailed guide on bypassing Google Apps Script limits to process very large JSON datasets. Rather than completely abandoning Apps Script, Dmitry shares an example zero-cost pipeline to process over 5 million spreadsheet cells without timing out. Here’s the breakdown of his architecture:

  1. Extract and compress the master data snapshot locally using Node.js and fflate (Dmitry highlights this could be hosted in Cloud Run).
  2. Encode to Base64 and slice it into text chunks.
  3. Automate multipart file uploads to Google Drive using the open-source Google Workspace CLI (gws).
  4. Use Apps Script as a thin proxy to fetch and return the text strings to the client browser.
  5. Reassemble, decompress and parse the chunks in the browser using Alpine.js.

A key component of this workflow  is the efficiency of the open-source Google Workspace CLI (gws). Rather than writing custom API upload scripts, it uses the gws +upload helper to automatically detect MIME types and execute multipart Drive uploads in a single command.

Crucially, this solution moves heavy computation to the developer machine and the user browser, keeping the Apps Script runtime focused purely on serving data. This relies on HtmlService for client-side processing and you can deploy it in standalone web apps or custom sidebars and dialogue boxes for editors like Google Docs and Sheets.

Dmitry also uses his open-source Apps Script Engine Template, which provides a pre-configured Vite, clasp and environment management setup to speed up development and allow you to standardise your build workflow. 

Read Dmitry’s full post for the complete code snippets and a look at the technical trade-offs of this approach. It is a fantastic example of using platform constraints to define a more efficient architecture!

Source: How I Shipped 341 MB of JSON Through Google Apps Script — and Lived to Tell the Tale

IntermediateSolutions

Orchestrating AI to Build a Free Looker Studio Connector for Airtable

Tags: ,
| | 0 Comments |

Looker Studio has supported custom community connectors for many years, allowing developers to bridge the gap between various APIs and their dashboards. While the capability exists, the technical barrier often leads users toward paid, third-party middleware. In a recent post, Toufik shares how they bypassed these monthly fees by building a free, self-hosted Airtable connector using Google Apps Script and AI coding tools.

TL;DR: Toufik demonstrates how to build a free, open-source Airtable connector for Looker Studio. By using Apps Script as the engine and an AI assistant to handle the implementation, the project was completed in about three hours. The result is a direct connection that avoids middleware and monthly subscriptions.

The Technical Barrier and the Apps Script Solution

As many developers know, building a community connector requires a specific understanding of the Apps Script environment: the UrlFetchApp for HTTP requests, the DataStudioApp service, and the semantics of field types. For those more comfortable with data analysis than backend services, this often feels like a steep climb.

Toufik highlights that the knowledge required to build these bridges hasn’t changed, but who holds that knowledge during the build has. By using Apps Script, they were able to create a direct connection where Airtable data appears as a native source. This approach ensures that data flows directly from the source to the dashboard through the user’s own account, removing the need for external servers or data collection.

Orchestrating AI with Domain Knowledge

A significant takeaway from this project is the method used to guide the AI assistant. Rather than asking the tool to write code immediately, Toufik created a “skill file.” This structured reference document provided the AI with domain-specific knowledge: the required function signatures for connectors (getAuthType(), getConfig(), getSchema(), and getData()), authentication types, and the specific manifest format rules required in appsscript.json.

As Toufik notes:

“The main cost was knowledge. And AI changed the price of knowledge. If your data lives behind an API and you can describe what you need, you’re closer to building it than you think.”

This shift in methodology suggests that for many niche connectors, the hurdle is no longer the typing, but the ability to describe the requirements and iterate through testing cycles. The build process involved testing the connector in Looker Studio, describing errors to the AI, and reviewing the proposed fixes. This iterative “test-describe-fix” loop allowed for the correct mapping of over 25 Airtable field types and the implementation of advanced features like pagination and rate-limit handling with exponential backoff.

New Avenues and the Risk of “Cheap” Code

This project serves as a reminder that the cost of building custom tools has dropped significantly. When developers can orchestrate an AI code assistant with a fundamental understanding of a platform like Apps Script, solutions that were previously behind paywalls become accessible. The repository includes not only the source code for authentication and schema detection but also the Claude Skill file used to prime the AI on the Looker Studio domain.

However, this ease of production brings its own set of challenges. As discussed in The New Stack, there is a growing concern that AI could flood the marketplace with low-quality, unmaintained “knockoffs” that lack the depth of human-led projects. The differentiator in Toufik’s approach is the rigor of the “skill file” and the domain expertise used to validate the output. For the Apps Script community, the value likely remains in the quality of orchestration and the commitment to maintaining the bridge once it is built, and the challenge for Google is maintaining the quality of its third party marketplaces.

For those interested in exploring the implementation or deploying their own version, Toufik has provided the full source code and the skill files on GitHub.

Source: How I Built a Free Airtable Connector for Looker Studio (AI-Assisted) | GitHub Repository

AIBeginnerDriveSolutions

Beyond external libraries: Google Workspace document and data processing with Gemini Code Execution

Tags: ,
| | 0 Comments |

Why use a dedicated app when you can simply ask Gemini to write and run the Python code for you? A look at the power of Google Apps Script and GenAI

For many Google Workspace developers, handling complex file formats or performing advanced data analysis has traditionally meant navigating the limitations of Apps Script’s built-in services. We have previously featured solutions for these challenges on Pulse, such as merging PDFs and converting pages to images or using the PDFApp library to “cook” documents. While effective, these methods often rely on loading external JavaScript libraries like pdf-lib, which can be complex to manage and subject to the script’s memory and execution limits.

While users of Gemini for Google Workspace may already be familiar with its ability to summarise documents or analyse data in the side panel, those features are actually powered by the same “Code Execution” technology under the hood. The real opportunity for developers lies in using this same engine within Apps Script to build custom, programmatic workflows that go far beyond standard chat interactions.

A recent project by Stéphane Giron highlights this path. By leveraging the Code Execution capability of the Gemini API, it is possible to offload intricate document and data manipulation to a secure Python sandbox, returning the results directly to Google Drive.

Moving beyond static logic

The traditional approach to automation involves writing specific code for every anticipated action. The shift here is that Gemini Code Execution does not rely on a pre-defined set of functions. Instead, when provided with a file and a natural language instruction, the model generates the necessary Python logic on the fly. Because the execution environment includes robust libraries for binary file handling and data analysis, the model can perform varied tasks without the developer needing to hardcode each individual routine. Notably, the model can learn iteratively which means if the generated code fails, it can refine and retry the script up to five times until it reaches a successful output.

While basic data analysis is now a standard part of Gemini for Workspace, having direct access to the library list in the Gemini sandbox opens up additional specialised, developer-focused avenues:

  • Dynamic Document Generation: Using python-docx and python-pptx, you can programmatically generate high-fidelity Office documents or presentations based on data from Google Workspace, bridging the gap between ecosystems without manual copy-pasting. [Here is a container bound script based on Stéphane code for Google Docs that generates a summary PowerPoint file]
  • Programmatic Image Inspection: Using Gemini 3 Flash, you can build tools that inspect images at a granular level. For example, a script could process a batch of site inspection photos, using Python code to “zoom and inspect” specific equipment labels or gauges, and then log those values directly into a database.

The mechanics and constraints

The bridge between Google Drive and this dynamic execution environment follows a straightforward pattern:

  1. File Preparation: The script retrieves the target file from Drive and converts the blob into a format compatible with the Gemini API.
  2. Instruction & Execution: Along with the file, a prompt is sent describing the desired outcome.
  3. The Sandbox: Gemini writes and runs the Python code required to fulfil the request.
  4. Completion: Apps Script receives the modified file or data and saves it back to the user’s Drive.

However, there are important boundaries to consider. The execution environment is strictly Python-based and has a maximum runtime of 30 seconds. Furthermore, developers should be mindful of the billing model: you are billed for “intermediate tokens,” which include the generated code and the results of the execution, before the final summary is produced.

Get started

For those interested in the implementation details, Stéphane has shared a repository containing the Apps Script logic and the specific configuration needed to enable the code_execution tool.

Source: Stéphane Giron on Medium | Code: GitHub Repository

AdvancedAISolutions

The Age of the Agent: Google’s Managed MCP Servers and Community Contributions

Tags: , ,
| | 0 Comments |

Image credit: Kanshi Tanaike

 

The “USB-C for AI” has officially arrived at Google.

If you have been following the rapid rise of Anthropic’s Model Context Protocol (MCP), you know it promises a standardised way for AI models to connect to data and tools. Until now, connecting an LLM to your Google Drive or BigQuery data meant building custom connectors or relying on fragmented community solutions.

That changed this week with Google’s announcement of fully managed, remote MCP servers for Google and Google Cloud services. But typically for the Google Workspace developer community, we aren’t just waiting for official endpoints—we are building our own local solutions too.

Here is an overview of the different approaches emerging for MCP tools and what the future looks like for Workspace developers.

The Official Path: Managed MCP Servers

Google’s announcement represents a massive shift in how they view AI agents. Rather than asking developers to wrap every granular API endpoint (like compute.instances.insert) into a tool, Google is releasing Managed MCP Servers.

Think of these as “Client Libraries for Agents.” Just as Google provides SDKs for Python or Node.js to handle the heavy lifting of authentication and typing, these managed servers provide a simplified, reasoned interface for agents.

The announcement lists a massive rollout over the “next few months” covering everything from Cloud Run and Storage to the Android Management API. The goal described is to make MCP the standard way agents connect to the entire Google ecosystem. To start with Google announced MCPs for:

  • Google Maps: instead of just raw data, the agent gets “Grounding Lite” to accurately answer location queries without hallucinating.
  • BigQuery: The agent can interpret schemas and execute queries in place, meaning massive datasets don’t need to be moved into the context window.
  • Google Kubernetes Engine (GKE): Agents can diagnose issues and optimize costs without needing to string together brittle CLI commands.

The Community Path: Privacy-First and Scriptable

While managed servers are excellent for scale and standardisation, there are some other notable approaches using local execution.

1. The Gemini CLI Workspace Extension As detailed in a recent tutorial by Romin Irani, the official google-workspace extension for the Gemini CLI takes a privacy-first approach. Instead of running in the cloud, the MCP server runs locally on your machine.

It uses your own local OAuth token, meaning your data flow is strictly Google Cloud <-> User's Local Machine <-> Gemini CLI. This is ideal for tasks like searching Drive, checking your Calendar, or drafting Gmail replies where you want to ensure no third-party intermediary is processing your data.

2. The Power of Apps Script (gas-fakes) For true customisability, Kanshi Tanaike has been pushing Google Apps Script. A recent proof-of-concept using gas-fakes CLI demonstrates how to build MCP tools directly using Apps Script.

This is a big step for Apps Script developers. It allows you to write standard GAS code (e.g., DriveApp.getFilesByName()) and expose it as a tool to an MCP client like Gemini CLI or Google Antigravity. Because it uses the gas-fakes sandbox, you can execute these scripts locally, bridging the gap between your local AI agent and your cloud-based Workspace automation.

The Future: A Universal MCP Strategy?

We are likely moving toward a world where every Google product launch includes three things: API documentation, Client SDKs, and an Official MCP Server Endpoint.

For developers, the choice will come down to granularity and control:

  • Use Managed Servers when you need reliable, standard access to robust services like BigQuery or Maps with zero infrastructure overhead.
  • Use Community/Local Tools (like the Workspace extension or gas-fakes) when you need rapid prototyping, deep customization, or strict data privacy on your local machine.

The “Agentic” future is here, and whether you are using Google’s managed infrastructure or writing your own tools, the ecosystem is ready for you to build.

Sources:

No CodeWorkspace Studio

Mastering Google Workspace Flows: A Comprehensive Guide to the New AI-Powered Automation Tool from Stéphane Giron

Tags: ,
| | 0 Comments |

With the announcement of Google Workspace Flows at Google Cloud Next 2025, Workspace developers and power users have been eager to see how this new platform integrates with the ecosystem we know and love. Currently available in the Gemini for Workspace Alpha programme, Workspace Flows promises to bridge the gap between simple tasks and complex, AI-driven processes.

In a fantastic new three-part series, Google Workspace expert Stéphane Giron takes us on a complete tour of the platform. From the initial interface to complex logic handling, this series is the perfect primer for anyone looking to automate their organisation’s daily grind.

Here is a breakdown of the series:

Part 1: A First Look The introductory article sets the stage, explaining how to enable Workspace Flows within the Admin console and providing a tour of the dashboard. Stéphane highlights how Flows is built with Gemini at its foundation, allowing users to describe workflows in natural language to generate automations instantly.

Part 2: The Starters (Triggers) In the second instalment, the focus shifts to the engine of every Agent: the Starter. Stéphane provides a deep dive into Application-based starters (reacting to events in Gmail, Drive, Chat, Sheets, Calendar, and Forms) versus Schedule-based starters. He details how granular these triggers can be—such as filtering emails by specific criteria before a flow even begins.

Part 3: Steps and Logic The final piece explores the “Steps”—the actions that happen after the trigger. The article covers:

  • Core App Steps: Standard actions like sending emails or creating Calendar events.
  • AI Integration: Using ‘Ask Gemini’ to reason, summarise, or transform content.
  • Logic: Implementing ‘Check if’ and ‘Decide’ steps to create dynamic paths.

Apps Script Integration

Of particular interest to the AppsScriptPulse community is the mention in Part 3 regarding Custom Steps. Stéphane notes that for ultimate power users, Workspace Flows will offer the ability to create custom steps using Google Apps Script. This feature will unlock the full potential of the ecosystem, allowing developers to build highly specific integrations that aren’t available out of the box.

Click the source links to find out more!

Sources

AIIntermediateSolutions

Automate In-Depth Research with Apps Script and a Gemini AI ‘Research Team’

Tags: ,
| | 0 Comments |

Automate research with this script. It turns a Google Sheet into an AI that plans, researches, and writes detailed reports on any topic.

The Gemini App (gemini.google.com) has a sophisticated Deep Research agent whose capabilities are incredibly powerful, but they are designed to tackle one complex topic at a time. The manual process of running each query and collating the results can however be very slow.

What if you could deconstruct the capabilities of Deep Research and build a similar agent which is instead orchestrated from a Google Sheet? Thankfully, Google Workspace Developer Expert, Stéphane Giron, has designed and shared an elegant solution that transforms Google Sheets and Apps Script into a powerful, automated, bulk research assistant.

Stéphane’s approach is built on a “Divide and Conquer” strategy, which he outlines in his detailed article on the project.

Instead of just asking a single AI to answer a complex question, this script acts as a manager for a specialised AI team… The process is broken down into three distinct phases:

  1. Phase 1: The Strategist (Plan): A powerful AI model analyses your main query and breaks it down into a logical plan of smaller, essential sub-questions.
  2. Phase 2: The Researcher (Execute): A fast, efficient AI model takes each sub-question and uses targeted Google searches to find factual, concise answers.
  3. Phase 3: The Editor (Synthesise): The strategist AI returns to act as an editor, weaving all the collected research and data into a single, cohesive, and well-written final report.

How the AI Research Team Works

The solution, which is available in full on GitHub, uses a clever combination of different Gemini models and tools, all orchestrated by Google Apps Script:

  • Input: The user simply lists all their research topics in a Google Sheet (e.g., in column A).
  • Phase 1 (Plan): The script loops through each topic. For each one, it calls the Gemini 2.5 Pro model, treating it as the “Strategist.” It uses Gemini’s function-calling capability to force the model to output a structured plan of sub-questions needed to answer the main query.
  • Phase 2 (Execute): The script then takes this list of sub-questions and calls the Gemini 2.5 Flash model for each one, treating it as the fast “Researcher.” This call uses the built-in Google Search tool (grounding) to find up-to-date, factual answers for each specific sub-question.
  • Phase 3 (Synthesise): Finally, with all the collected research, the script calls Gemini 2.5 Pro one last time. In this “Editor” role, the model receives the original query and all the question/answer pairs, synthesising them into a single, comprehensive report.
  • Output: The script creates a new Google Doc for this final report and places a link to it directly in the Google Sheet, next to the original topic.

This “AI team” approach is a fascinating pattern we’re beginning to see emerge in the community. It strongly echoes the “AI Scrum Master” concept shared by Jasper Duizendstra at the recent Google Workspace Developer Summit in Paris. Both solutions smartly move away basic prompting and instead orchestrate a team of specialised AIs, leading to a far more robust and scalable workflow.

Stéphane’s script is highly customisable, allowing you to set the number of sub-questions to generate, define the output language, and pass the current date to the models to ensure the research is timely.

This is a fantastic example of how to build sophisticated, autonomous AI agents inside Google Workspace. A big thank you to Stéphane Giron for sharing this project with the community.

Get Started

You can find the complete code, setup instructions, and a deeper dive into the architecture at the links below:

Source: Bulk Deep Research with Gemini and Google Apps Script + Code Repository: Bulk-Deep-Research on GitHub

AdvancedCommunity NewsLibrarySolutionsV8

Apps Script Engine v2.0 is Here! Your Workflow Just Got a TypeScript Power-Up 🚀

Tags: , , , ,
| | 0 Comments |

 

You heard it right. This is the update you’ve been waiting for. Apps Script Engine now has full-blown TypeScript support! 🤯

We’re talking server-side .gs files and client-side HtmlService code. The whole shebang. While clasp has been on-again, off-again with its TypeScript support, we decided to go all in and deliver the robust, seamless experience you deserve.

Getting started is ridiculously simple. Just tack on the --ts flag during installation:

npx apps-script-engine [directory] --ts

Why TypeScript is a Game-Changer for Apps Script

For larger or more complex Apps Script projects, the introduction of TypeScript offers substantial benefits that can improve code quality and developer productivity:

  • Static Typing: Helps catch common errors during development rather than at runtime, preventing entire classes of bugs related to data types.
  • Enhanced Autocompletion: Provides intelligent code suggestions and autocompletion in the IDE, speeding up the development process.
  • Improved Code Readability: Makes code easier to understand and maintain, as types explicitly define the data structures being used.

What’s New in Version 2.0?

This release is packed with features that modernise the Apps Script development experience:

  • Full TypeScript Support: Write modern, type-safe JavaScript for both frontend and backend code.
  • ES6+ Modules: Organise your code into clean, reusable modules.
  • Frontend Frameworks: Comes with out-of-the-box support for Alpine.js and Tailwind CSS (including Daisy UI).
  • NPM Modules: Leverage the vast ecosystem of NPM modules in your server-side and client-side code.
  • Robust Mocking: The mocking system for google.script.run has been re-engineered to allow for easy simulation of both success and failure handlers during local development.
  • Migration to Vitest: The testing framework has been switched from Jest to Vitest, offering faster performance and a simpler configuration.
  • Gemini CLI Integration: A new GEMINI.md file is included in the project template, providing the Gemini CLI with the necessary context to assist with coding and debugging tasks.
  • CI/CD and Environment Management: The engine includes built-in support for GitHub Actions workflows and managing multiple deployment environments (DEV, UAT, PROD).

This update positions Apps Script Engine as a powerful tool for developers who want to apply modern web development practices to the Google Workspace platform.

Source: Apps Script Engine v2.0 is Here! Your Workflow Just Got a TypeScript Power-Up 🚀

SolutionsWeb App

Taming the Timeout: A Robust Webhook Strategy for Apps Script from Max Makhrov

Tags: ,
| | 0 Comments |

Webhooks are a powerful way for developers to connect different applications, allowing them to automatically send data to a Google Apps Script project whenever an event occurs. However, this powerful technique comes with a significant challenge: if your script takes too long to process an incoming request, the sending service will time out, leading to lost data and unreliable automations.

In a recent article, Google Workspace Developer Max Makhrov shares a clever and effective architecture designed to make your webhooks both fast and reliable.

The Problem: When a Few Seconds is Too Long

The core issue is that services sending webhooks—like GitHub, Shopify, or Stripe—expect a nearly instant 200 OK response. These services have strict timeout policies, often between 5 to 10 seconds. If your doPost(e) function is busy with complex logic, writing to a spreadsheet, or making other API calls, it can easily fail to respond in time, causing the service to report a delivery failure.

The Solution: Cache Now, Process Later

Max’s approach decouples the initial reception of data from the heavy processing. The strategy is elegantly simple:

  1. Immediate Caching: The doPost(e) function is kept lean. Its only job is to immediately write the raw, incoming webhook data to Apps Script’s CacheService.
  2. Instant Response: With the data safely stored, the function quickly returns a success message, satisfying the sending service well within its required timeout window.
  3. Asynchronous Processing: A separate, time-driven trigger runs another function on a regular schedule (e.g., every minute). This function retrieves one or more tasks from the cache and performs the long-running processes.

To manage the tasks in the cache, Max introduces the concept of using a lightweight collection, which allows multiple webhook payloads to be queued and processed in an orderly fashion. Crucially, this pattern also uses LockService to prevent multiple processing functions from running simultaneously and trying to handle the same data.

While CacheService is perfect for this, it’s important to remember its limits: the 100KB size limit per item can be a challenge for webhooks with large payloads, and items expire after 10 minutes, so your processing trigger must run frequently enough to handle the workload.

It’s worth noting that this “fire and forget” pattern is ideal for notification-style webhooks, where the sending service only needs a 200 OK status to confirm receipt. For interactive webhooks that require a specific JSON response to be sent back immediately (like a Slack command), this asynchronous approach would not be suitable.

Here is a look at the lean doPost(e) function that captures the incoming data:

function doPost(e) {  
  try {  
    // Immediately write the raw payload to CacheService  
    writeHook2Cache\_(e);  
  } catch (err) {  
    // If caching fails, log the error  
    set2Memory\_(webhookKeys.error, err);  
  }  
  // Instantly return a 200 OK success response  
  return ContentService  
   .createTextOutput(JSON.stringify({status: 'success'}))  
   .setMimeType(ContentService.MimeType.JSON);  
}

This asynchronous architecture is a powerful pattern for any developer building robust integrations.

A big thank you to Max Makhrov for sharing this valuable technique with the community! You can find a more detailed explanation and links to the complete code on his Medium page.

Source: Using Collections for Handling Web-Hooks with App Script