workflow recipe
n8n Database Row to Webhook Workflow for Outbound Events
Use Schedule Trigger to poll, Postgres or another database node to read new rows, Set to shape the payload, and HTTP Request to send the webhook.
Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.
Quick Answer
Use Schedule Trigger to poll, Postgres or another database node to read new rows, Set to shape the payload, and HTTP Request to send the webhook.
Problem Pattern
Database-to-webhook automations fail when rows are reprocessed, payloads leak internal fields, or the receiving API treats retries as duplicate events.
Key Facts
- Polling
- Schedule Trigger can check the database on a predictable cadence.
- Source
- Database nodes should query only rows that need sending.
- Payload
- Set should expose only the fields the receiver needs.
- Idempotency
- Store a sent timestamp, status, or event ID to avoid duplicates.
Recommended Steps
- Query only unsent or recently changed rows from the database.
- Use Set to build a minimal outbound webhook payload.
- Send the payload with HTTP Request.
- Record success, failure, status code, and sent timestamp back to the database when possible.
- Retry carefully with an idempotency key or event ID.
Verification
- A new row sends one outbound request.
- The payload excludes internal-only fields.
- Successful rows are marked as sent.
- Retry behavior does not duplicate the receiver's action.
Warnings
- Do not expose internal database columns to third-party webhook receivers.
- A retry after partial success can duplicate external side effects.
- Polling without a sent marker can resend the same rows forever.
Best For
- Outbound event bridges
- Legacy database integrations
- Simple system-to-system sync
Not For
- High-volume streaming pipelines
- Exactly-once delivery without dedicated infrastructure
Common Mistakes
- Selecting every row on every run.
- Skipping sent status updates.
- Sending raw database records.
- Retrying non-idempotent operations blindly.
Examples
Schedule Trigger: every 5 minutes
Postgres: select rows where webhook_sent_at is null
Set: event_id, type, public fields
HTTP Request: POST receiver webhook
Postgres: update webhook_sent_atFAQ
Can this guarantee exactly-once delivery?
No. It can reduce duplicates with sent markers and idempotency keys, but exactly-once delivery needs stronger infrastructure.
Should I send the whole row?
No. Build a minimal payload that contains only fields the receiver needs.