Retiring the Poll That Waits on an Overnight Batch — An Apps Script doPost Sink for Gemini Signals

Put the receiver in a Web App doPost

You stand up the receiver by deploying the script as a Web App. A few deployment settings are non-negotiable.

"Anyone can access" may feel uncomfortable. That is exactly why we put a hard-to-guess token in the URL itself and back the payload with an authoritative check. The idea is layered defense rather than a single wall. The webhook destination you register looks like this, for example:

https://script.google.com/macros/s/XXXXXXXX/exec?t=REPLACE_WITH_LONG_RANDOM_TOKEN

Every time you change code you redeploy a new version, but if you update the deployment as a version from "Manage deployments," the /exec URL is preserved. Creating a brand-new deployment changes the URL, leaving the sender pointed at a stale address and dropping events. This is the step most people trip over in operation.

doPost returns fast: verify and enqueue, nothing more

doPost has its own per-execution time limit, and trying to finish heavy apply work inline is risky. Worse, webhook senders retry when the response is slow or returns an error, and retries mean duplicate deliveries.

So doPost's job is narrowed to token verification and enqueuing the operation name into a durable queue, then it returns 200 immediately. The apply is left to a downstream trigger.

const WEBHOOK_TOKEN = 'REPLACE_WITH_LONG_RANDOM_TOKEN';
 
function doPost(e) {
  // 1) First-pass screen with a hard-to-guess token (headers unreadable, so use the query)
  if (!e || !e.parameter || e.parameter.t !== WEBHOOK_TOKEN) {
    return json_({ ok: false }); // always 200 so we leak nothing to an attacker
  }
 
  // 2) Pull only the operation name from the body (do not trust its contents)
  let opName = '';
  try {
    const body = JSON.parse(e.postData.contents || '{}');
    opName = String(body.name || body.operation || '').trim();
  } catch (err) {
    return json_({ ok: false });
  }
  if (!opName) return json_({ ok: false });
 
  // 3) Enqueue durably and return at once (heavy confirm/apply goes downstream)
  enqueue_(opName);
  return json_({ ok: true });
}
 
function json_(obj) {
  return ContentService
    .createTextOutput(JSON.stringify(obj))
    .setMimeType(ContentService.MimeType.JSON);
}
 
function enqueue_(opName) {
  const lock = LockService.getScriptLock();
  lock.waitLock(5000);
  try {
    const props = PropertiesService.getScriptProperties();
    const q = JSON.parse(props.getProperty('inbound_q') || '[]');
    if (q.indexOf(opName) === -1) q.push(opName);
    props.setProperty('inbound_q', JSON.stringify(q));
  } finally {
    lock.releaseLock();
  }
}

The LockService.getScriptLock around enqueue keeps the queue's read-modify-write from breaking when several signals overlap in a short window. Hold the lock briefly, and keep it outside heavy work like confirmation or apply — that is the rule.

Don't take the signal at face value: confirm with operations.get

A downstream trigger — say, one a minute, or a single one fired from doPost via ScriptApp.newTrigger — confirms the queued operation names one by one. Only here do we ask the API, and only after seeing done is true with our own eyes do we apply.

function drainInbound() {
  const props = PropertiesService.getScriptProperties();
  const lock = LockService.getScriptLock();
  lock.waitLock(5000);
  let q;
  try {
    q = JSON.parse(props.getProperty('inbound_q') || '[]');
    props.setProperty('inbound_q', '[]'); // take everything and clear
  } finally {
    lock.releaseLock();
  }
 
  const requeue = [];
  for (const opName of q) {
    const res = UrlFetchApp.fetch(
      'https://generativelanguage.googleapis.com/v1beta/' + opName,
      { headers: { 'x-goog-api-key': getApiKey_() }, muteHttpExceptions: true }
    );
    if (res.getResponseCode() !== 200) { requeue.push(opName); continue; }
    const op = JSON.parse(res.getContentText());
    if (!op.done) { requeue.push(opName); continue; } // not yet, put it back
    applyOnce_(opName, op); // apply only what we confirmed done
  }
  if (requeue.length) enqueueMany_(requeue);
}

The signal is only a prompt. The real completion and result are whatever operations.get returns. Because this step exists, a forged signal can never make us apply something that hasn't finished. Apps Script's inability to verify a header signature is fully defused right here.

Fold duplicate deliveries with an idempotency key

Webhooks are fundamentally at-least-once: they arrive at least once, sometimes more. A slow response makes the sender retry, or a reconciliation sweep collides with a live signal, and you risk applying the same operation twice. So we insert an idempotency ledger that records what has already been applied.

function applyOnce_(opName, op) {
  const applied = PropertiesService.getScriptProperties();
  const key = 'applied:' + opName;         // the operation name is the idempotency key
  const lock = LockService.getScriptLock();
  lock.waitLock(10000);
  try {
    if (applied.getProperty(key)) return;  // already applied, do nothing
    applyResult_(opName, op);              // the actual write-back (side effect)
    applied.setProperty(key, String(Date.now()));
  } finally {
    lock.releaseLock();
  }
}

The operation name alone is a fine idempotency key. If the ledger grows, sweep keys past a certain age before you brush against the 500KB total limit on PropertiesService, or offload to an indexed store on Drive. This matters more as your number of automations grows, so it's reassuring to build the cleanup step early.

A safety net for misses: a low-frequency reconciliation sweep

Webhooks usually arrive, but there is no guarantee they always will. That is precisely why we don't discard polling outright — we keep a much rarer reconciliation sweep as insurance. Once every few hours, it checks only the operations recorded as in-flight and recovers any that finished without a signal.

// e.g. runs once every 6 hours
function reconcileInflight() {
  const props = PropertiesService.getScriptProperties();
  const inflight = JSON.parse(props.getProperty('inflight_ops') || '[]');
  const still = [];
  for (const opName of inflight) {
    const res = UrlFetchApp.fetch(
      'https://generativelanguage.googleapis.com/v1beta/' + opName,
      { headers: { 'x-goog-api-key': getApiKey_() }, muteHttpExceptions: true }
    );
    const op = JSON.parse(res.getContentText());
    if (op.done) applyOnce_(opName, op);
    else still.push(opName);
  }
  props.setProperty('inflight_ops', JSON.stringify(still));
}

Five-minute polling was 288 runs a day; a six-hour sweep is four. And because it looks only at in-flight operations, its empty checks are minimal. Build the premise that signals rarely get lost, then keep only a minimal catch for the times they do. This two-tier arrangement feels realistic for automations you run solo.

What actually changed after folding the poll

Here are results from my own app-review classification pipeline (one to three batches overnight), comparing the old polling to this article's design. The numbers shift by environment, but the trend should carry.

What changed most in daily feel was latency. Overnight results are "already applied when I wake up" either way, but a batch I run by hand during the day now returns in seconds instead of a wait of minutes. That shortness quietly speeds up iteration.

How much should you move to webhooks

Finally, the judgment axes for the switch. Moving everything to webhooks is not the answer.

The point is to split the roles: the webhook is "the signal that notices fast," operations.get is "the ground of correctness," and the sweep is "insurance against misses." Even the constraint of not reading headers in Apps Script stops being a weakness inside this division of labor. If anything, the premise of "don't trust the notification" led me to a sturdier receiver.

The more a job works overnight, the more your impression of it turns on whether the morning feels quietly settled. Fold away the empty polls, and go confirm only when you need to. I hope this helps make your own automation a little lighter. Thank you for reading.