Capture Supabase row updates and record recovery receipts with Rewind

Description

Quick overview
This workflow manually updates a specific Supabase row via custom RPCs, captures verified before/after snapshots, and records the change as a recovery receipt in Rewind using HTTP requests.

How it works
Runs manually to start a single test update.
Sets the Supabase project URL, Rewind base URL, table alias, target row UUID, patch fields, and connection name, then validates these inputs.
Calls a Supabase REST RPC to read the current row revision and verifies a valid version is returned.
Calls a Supabase REST RPC to apply the patch only if the expected version matches, returning atomic before/after snapshots and the new revision.
Builds and validates a Rewind operation payload including idempotency key, resource identifier, and the captured snapshots and revision.
Sends the payload to the Rewind API to record the operation for later approval and recovery.

Setup
Use a development Supabase project, n8n, and a Rewind account. From https://rewind.kanishq.dev/#connect download and run the connector SQL, then the disposable demo-table SQL.
Create an HTTP Header Auth credential in n8n with the Supabase server secret as apikey. Select it on Read row and Capture update. Keep credentials only in n8n; none are included in this template.
Create an HTTP Header Auth credential in n8n for Rewind using Authorization: Bearer , and select it for the Rewind recording request.
Update the Supabase project origin URL, Rewind base URL, alias, row UUID, patch JSON, and connection name in the configuration step to match your environment and Rewind worker connection.

Customization
Only adapt registered tables and existing scalar fields after testing. Updates only: no inserts, deletes, messages or pre-install recovery. Leave schedules inactive until tested.

Additional info
Recovery is a separate workflow. A person reviews and approves the recorded change in Rewind; approval queues work. The matching worker checks the current revision before restoring. Verify the actual Supabase row after the worker runs. Check active/5 becomes inactive/3 and returns to active/5. Repeat with a later edit to confirm conflict protection. If receipt delivery fails, retry only Record operation with saved input; never repeat the provider update.