Google Apps Script Form Receiver: How It Really Works

A Google Apps Script form receiver is a tiny web app, deployed inside your own Google account, that accepts form submissions over HTTPS and appends them to your spreadsheet. In June 2026, Google promoted Apps Script to a Google Workspace core service with enterprise-grade data protection (Google Workspace Updates, 2026), so the platform underneath now carries Workspace-level commitments.

That architecture is the whole point. Because the receiver runs in your account, form data travels from your WordPress site straight into your Google account and nowhere else. No middleware vendor stores a copy, no automation platform logs your leads in its task history, and no third party ever touches a submission on the delivery path (the optional AI add-ons are the one disclosed exception).

One note before we dive in: since v1.12.0 (2026-07-24), SheetLink Forms also offers a one-click Google Sheets connect - an OAuth flow using the drive.file scope and the Google file picker, so the plugin only gets access to the spreadsheets you pick or create, never your whole Drive. This article covers the classic self-hosted receiver method, which remains fully supported and is the option to choose if you want no OAuth in the picture at all.

This post demystifies the moving parts one at a time: doPost(e), the secret token check, appendRow, the guards around them, and why this design beats handing an OAuth'd middleman service broad keys to your spreadsheet.

When you deploy a script as a web app, Google assigns it a unique HTTPS URL. Any POST request sent to that URL wakes the script and runs a function named doPost(e), where e is an object carrying everything the sender included: form fields, query parameters, and the raw request body.

In other words, the script is a webhook receiver. Your WordPress site plays the sender: on each form submission it makes one HTTPS POST to your script's URL with the field values in the payload. Google handles the servers, the TLS certificates, the scaling, and the uptime, because the endpoint runs on Google's own infrastructure.

Inside doPost, the script reads fields from e.parameter, runs its checks, and writes a row. The entire receiver is typically a few dozen lines of JavaScript you can read in one sitting. That readability is itself a security feature: you can audit every single line of the code that handles your lead data.

Because the data path defines who your data processors are. With an Apps Script receiver, submissions travel from your site to your script to your sheet, entirely inside infrastructure you control or already trust. With middleware, every submission detours through a vendor's servers, where it is received, stored, logged, and retained under that vendor's policies rather than yours.

Middleware platforms are legitimate tools, but they are a third party in your data flow by design. Their task histories keep copies of your leads' names, emails, and messages. That is an extra breach surface, an extra subprocessor for your privacy policy, and an extra recurring bill that scales with volume. We broke down those costs in Make vs Zapier vs a direct plugin.

The receiver model removes the detour instead of trying to secure it. There is nothing extra to trust because there is nobody in the middle: no vendor dashboard holds your submissions, no vendor outage can eat them, and no vendor pricing change can hold your pipeline hostage.

Three layers do the work: transport, authentication, and content. Transport is HTTPS end to end, since Apps Script web app URLs are TLS-only. Authentication is a shared secret token checked at the top of doPost, so requests without the right token are rejected before any spreadsheet code runs. Content hardening handles whatever attackers put inside the fields themselves.

The main content risk is formula injection: a "name" field that begins with an equals sign, a plus, a minus, or an at sign turns into live spreadsheet code the moment it is written to a cell, and a hostile formula can exfiltrate data from the sheet. A well-built receiver neutralizes those values so they land as inert text instead of executing.

You also keep unilateral kill authority. Re-deploying the script rotates its URL, and deleting the deployment shuts the endpoint off entirely. No support ticket to a vendor, no waiting on someone else's queue: revocation is one click inside your own account, effective immediately.

SheetLink Forms automates exactly this pattern. The plugin's wizard walks you through deploying the Apps Script receiver into your own Google account in a few minutes, then sends submissions from 12 major form plugins to it in real time. On this classic method there are no Google API keys, no OAuth, and no third-party data processor anywhere on the Sheets path. (If you would rather skip the deployment entirely, the one-click Google Sheets connect added in v1.12.0 is the alternative; the receiver remains the fully self-hosted choice.)

The receiver it sets up includes the secret token check and the formula-injection guard described above out of the box, so the security posture in this post is the default, not an upgrade. Follow the Google Sheets setup docs for the walkthrough, or the plain-English version in WordPress forms to Google Sheets without code.

Because the deployment lives in your account, you keep everything this post promised: full auditability of the script, one-click revocation, and a data path with nobody standing in the middle of it.