n8n Workflow: Capture Supabase Row Updates w/ Rewind Receipts

Capture Verified Supabase Row Changes in Rewind—Using Rewind Receipts

This n8n workflow performs a controlled update to a specific Supabase row via custom RPCs, captures verified before/after snapshots, and records the change as a Rewind recovery receipt through HTTP requests.

What this workflow does

Built for a single, manual test update, the workflow:

• Runs manually to update one target row at a time.
• Sets and validates inputs including your Supabase project URL, Rewind base URL, table alias, target row UUID, patch fields, and connection name.
• Reads the current row revision by calling a Supabase REST RPC and confirms a valid version is returned.
• Applies the patch atomically only when the expected revision matches, via another Supabase REST RPC—returning before/after snapshots and the new revision.
• Builds a Rewind operation payload with an idempotency key, resource identifier, captured snapshots, and the revision.
• Sends the payload to the Rewind API to record the operation for later approval and recovery.

Use cases

• Test a sensitive Supabase update flow safely before enabling broader writes.
• Generate a Rewind receipt for an auditable “change record” tied to exact row state.
• Validate revision-based concurrency behavior (expected version matching) during integration.
• Use in SaaS operations when you need recovery-ready logs for row-level changes.

Technical details

• Supabase REST RPC calls to read revision and patch with revision checks.
• Rewind HTTP API call to record the recovery receipt.
• n8n nodes used: Set, Code, Sticky Note, HTTP Request, Manual Trigger.
• Credentials: HTTP Header Auth for Supabase (apikey as server secret) and Rewind (Authorization: Bearer <RECORDING_KEY>).

Get a repeatable Supabase row update workflow that produces verified Rewind receipts—so you can recover confidently when it matters.