Create a Web API with Google Apps Script and Use Google Drive as CMS

When developers need a Content Management System (CMS) for a new website or application, they usually reach for heavy-duty solutions like WordPress, Contentful, or Strapi. While powerful, these platforms often introduce unnecessary complexity, require dedicated database hosting, and force non-technical users to learn a completely new interface.

But what if you could use a tool that everyone in your organization already knows how to use? Google Drive and Google Docs offer a world-class collaborative editing experience. By leveraging Google Apps Script (GAS), developers can expose Google Drive folders and Google Docs as a fully functional, serverless REST API, effectively transforming Google Workspace into a highly collaborative, zero-cost headless CMS.

Google Apps Script is a rapid application development platform based on JavaScript. It runs directly on Google's cloud infrastructure and provides built-in, native objects to interact with Google Workspace applications (Docs, Sheets, Gmail, Drive, etc.).

The beauty of GAS is that it requires absolutely zero server setup. You don't need AWS, you don't need a Node.js server, and you don't have to worry about scaling. When you write a script, Google executes it. More importantly, GAS allows you to deploy scripts as "Web Apps," meaning they can listen for standard HTTP GET and POST requests, making them perfect for building lightweight APIs.

The architecture for this headless CMS is remarkably simple yet highly effective.

The Database (Google Drive): You create a specific folder in Google Drive. Inside this folder, you create standard Google Docs. These documents represent your "blog posts" or "web pages." The content is written naturally, utilizing headings, bold text, and lists.

The API Layer (Google Apps Script): You write a standalone Apps Script that acts as the router. When an external frontend application sends an HTTP GET request to the Apps Script URL, the script reads the contents of the Google Drive folder, opens the relevant Google Docs, extracts the text (or HTML), packages it into a JSON payload, and returns it to the client.

To create a Web API in Google Apps Script, you must define a specific function called doGet(e). This function is automatically triggered whenever an HTTP GET request hits your published Web App URL.

Inside doGet(e), the e parameter contains the query string parameters. For example, if a user requests ?articleId=12345, your script can extract that ID using e.parameter.articleId. Once the script has the ID, it uses the DriveApp and DocumentApp services to locate the file, read its contents, and construct a JavaScript object. Finally, to return the data to the client, you must return a ContentService.createTextOutput() object, setting the MimeType to JSON.

Fetching raw text from a Google Doc is easy, but raw text isn't very useful for a web page—you lose all formatting. The real power comes from extracting the structured data.

Using the DocumentApp service, you can iterate through the elements of a document (paragraphs, list items, tables). As you iterate, you can check the element's type. If it's a HEADING1, you wrap the text in an <h1> tag. If it's a LIST_ITEM, you wrap it in an <li> tag. By building a simple parser within your Apps Script, you can dynamically convert a standard Google Doc into clean, semantic HTML that your frontend application can safely inject using dangerouslySetInnerHTML (in React) or equivalent methods.

When deploying your Apps Script as a Web App, you are presented with access settings. To use it as a public API, you must set "Execute as" to "Me" and "Who has access" to "Anyone".

This configuration means the script accesses your Google Drive using your permissions, but anyone with the API URL can trigger the script without needing to log into Google. Because the script is running on script.google.com, Google handles Cross-Origin Resource Sharing (CORS) automatically, allowing your frontend (hosted on Vercel, Netlify, etc.) to fetch the data seamlessly via standard JavaScript fetch() calls.

Once the API is deployed, consuming it is no different than fetching data from Contentful or a Node.js server. In a modern framework like Next.js or Nuxt, you can fetch the data during the build process (Static Site Generation) or on the server (Server-Side Rendering).

Because Google Apps Script does have rate limits (and is not designed to handle thousands of requests per second), the best practice is to use Static Site Generation (SSG) or implement a strong caching layer (like Redis or Next.js ISR). Your server fetches the Google Doc JSON payload once, caches the HTML, and serves the cached version to your thousands of users, ensuring blazing-fast load times while avoiding Google's quota limits.

Using Google Drive and Apps Script as a headless CMS is an incredibly elegant solution for small to medium-sized projects, internal company portals, and rapid prototypes. It provides a familiar editing interface for content creators, requires zero database hosting fees, and integrates perfectly with modern frontend frameworks.

However, for massive enterprise applications requiring complex relational data, strict version control, and high-throughput real-time APIs, traditional CMS architectures remain necessary. At MetaDesign Solutions, our cloud architecture experts can help you evaluate your requirements and build the perfect headless CMS solution—whether it's an innovative Google Workspace integration or a highly scalable enterprise platform. Contact us today to optimize your content delivery workflow.