Webhook redelivery is the quiet source of duplicate rows in almost every “log this to a spreadsheet” recipe, since most payment processors will resend an event if their retry window expires before your endpoint acknowledges it. Dedup on transaction ID from day one rather than cleaning up duplicates later.
Automation
Log incoming webhook events to Google Sheets
A scenario prompt that converts a described webhook-to-spreadsheet logging workflow into a recipe, resolving schema drift, rate limits, and duplicate-row edge cases.
Works with Claude / GPT190 uses★ 3.9
The prompt
automation-webhook-to-google-sheets-logging
An operations team describes their process like this: "Whenever our payment processor sends a webhook for a completed transaction, I want a new row added to a Google Sheet with the date, customer email, amount, and transaction ID, so finance has a running log without needing processor dashboard access." AVAILABLE TOOLS: [Payment processor webhook (trigger), Uncanny Automator, Google Sheets] Turn this into an implementation-ready automation recipe, thinking through what the plain description leaves ambiguous: 1. Trigger: the exact webhook event type to listen for, distinguishing a genuinely completed transaction from a "payment.succeeded" event that's later followed by a "charge.refunded" event for the same transaction ID, since the sheet needs to reflect the refund, not just silently keep the original row as if nothing changed. 2. Conditions: state the exact dedup logic against transaction ID, since payment processors are known to redeliver the same webhook multiple times if their retry logic doesn't get a fast enough acknowledgment, and a naive append-only recipe would create duplicate rows for the same transaction. 3. Actions in order: look up the transaction ID in the sheet first, update the existing row if a refund event arrives for it, otherwise append a new row, then format the amount as currency and the date in a consistent timezone rather than whatever the webhook payload happens to use. 4. Failure handling: if Google Sheets' API rate limit is hit during a burst of transactions, should events queue and retry, and how do you guarantee ordering isn't scrambled when the retry catches up out of sequence. 5. One edge case specific to this exact workflow: a webhook payload missing the customer email field due to a guest checkout with only a phone number on file. Decide what placeholder or fallback value the recipe writes instead of leaving the cell blank in a way that breaks a later VLOOKUP. Replace the workflow description and available tools with your own.