Webhook Idempotency and Retry Safety Design Prompt

You are an expert automation architect specializing in webhook systems, idempotency, retry safety, replay behavior, partial failure handling, API integrations, logging, monitoring, and operational reliability.

Your task is to design a safe webhook or automation workflow that prevents duplicate actions, handles retries correctly, manages partial failures, and creates a reliable recovery process.

Context:
Workflow goal: [Workflow goal]
Trigger event: [Trigger event]
Systems involved: [Systems involved]
Webhook source: [Webhook source]
Webhook receiver: [Webhook receiver]
Actions performed: [Actions performed]
Data payload: [Data payload]
External APIs: [External APIs]
Duplicate risk: [Duplicate risk]
Retry behavior: [Retry behavior]
Partial failure scenarios: [Partial failure scenarios]
Logging requirements: [Logging requirements]
Rollback options: [Rollback options]
Definition of done: [Definition of done]

Important constraints:

* Do not assume retries are safe.
* Do not allow duplicate payments, duplicate emails, duplicate invoices, duplicate records, duplicate account actions, or repeated destructive actions.
* Include idempotency strategy, retry rules, replay behavior, and partial failure handling.
* Separate automatic retries from manual replay.
* Include logging, monitoring, alerts, and auditability.
* Include human review for high-risk actions.
* Keep the design practical for real no-code, low-code, and custom-code workflows.
* If information is missing, state assumptions clearly.
* Prioritize data integrity, user trust, financial safety, and operational recovery.

Task:

1. Summarize the workflow.
   Explain:

* What the workflow is meant to do
* What event triggers it
* Which systems are involved
* What data moves between systems
* Which actions are high-risk
* Where failure could cause duplicates or data inconsistency

2. Identify duplicate and replay risks.
   Analyze:

* Duplicate webhook delivery
* Retry after timeout
* Retry after partial API success
* User resubmission
* Queue worker retry
* Manual replay
* Network failure
* External API uncertainty
* Race conditions
* Out-of-order events
* Same event received multiple times

For each risk, explain the possible damage.

3. Define the idempotency strategy.
   Recommend:

* Idempotency key source
* Event ID or transaction ID to store
* Where to store processed events
* How long to retain idempotency records
* How to handle repeated requests
* How to detect duplicate actions
* How to make each workflow step safe to retry
* How to avoid creating duplicate records in downstream systems

4. Define retry rules.
   Create retry guidance for:

* Safe retries
* Unsafe retries
* Retry delay
* Retry limit
* Exponential backoff
* Dead-letter queue or failed task list
* Manual review after repeated failure
* When to stop retrying
* What should trigger an alert

5. Define partial failure handling.
   For each workflow step, explain:

* What happens if the step succeeds
* What happens if the next step fails
* What data should be saved before moving forward
* How to resume safely
* How to avoid repeating completed actions
* How to compensate or roll back where needed
* What requires human review

6. Create a logging and audit plan.
   Include:

* Event ID
* Idempotency key
* Payload summary
* Source system
* Destination system
* Workflow step status
* API response status
* Retry count
* Error message
* Timestamp
* User or account affected
* Manual action taken
* Final outcome

7. Create a replay and recovery plan.
   Define:

* When replay is allowed
* Who can replay events
* What checks must happen before replay
* How to replay only failed steps
* How to prevent duplicate completed steps
* How to mark events as resolved
* How to recover from unknown API state
* How to document recovery actions

8. Create a monitoring and alerting plan.
   Recommend:

* Failure rate alerts
* Retry threshold alerts
* Duplicate event alerts
* Dead-letter queue alerts
* Payment or invoice mismatch alerts
* Missing downstream record alerts
* Slow processing alerts
* Manual review queue alerts
* Daily reconciliation checks

9. Create a workflow safety checklist.
   Include:

* Pre-build checks
* Idempotency checks
* Retry checks
* Duplicate prevention checks
* Logging checks
* Security checks
* Privacy checks
* Monitoring checks
* Recovery checks
* Human review checks

10. Define test scenarios.
    Create practical test cases for:

* Normal successful event
* Duplicate event
* Retry after timeout
* API success but response failure
* First step succeeds and second step fails
* Out-of-order event
* Invalid payload
* Missing required field
* Manual replay
* External API outage
* Rollback or compensation scenario

For each test, include expected behavior.

11. Provide final recommendations.
    Summarize:

* Safest workflow design
* Required idempotency controls
* Retry rules to implement
* Logs to capture
* Alerts to configure
* Recovery process
* Risks that still need human review

Output format:

## Workflow Summary

## Duplicate and Replay Risks

## Idempotency Strategy

## Retry Rules

## Partial Failure Handling

## Logging and Audit Plan

## Replay and Recovery Plan

## Monitoring and Alerting Plan

## Workflow Safety Checklist

## Test Scenarios

## Final Recommendations

Verification:
Before finalizing, check that:

* Duplicate actions are prevented.
* Retry behavior is clearly defined.
* Partial failures have a safe recovery path.
* Manual replay cannot repeat completed actions.
* Logs are sufficient for debugging and audit.
* Monitoring and alerts are included.
* High-risk actions have human review.
* The workflow is practical for real automation tools or custom code.
* The recommendations protect data integrity, payments, user trust, and operational reliability.

Begin the webhook idempotency and retry safety design now.