Mock Webhooks

Many real APIs do not just respond to your request — they also send a webhook to notify your system of something that happened asynchronously. Payment confirmations, job completions, and status change notifications are common examples. Mock webhooks let you simulate those outbound callbacks so you can test your webhook handler without a live upstream. When a mock rule matches an incoming request, GoDizzy serves the mock response immediately, then fires your configured webhooks in the background — one after another, in the order you define them.

​

How mock webhooks work

Each mock rule has an ordered list of webhook callbacks. After GoDizzy returns the mock response to the caller:

1. GoDizzy processes the webhook list from top to bottom.
2. For each webhook, it waits the configured delay (in milliseconds), then sends the HTTP request.
3. Each webhook is delivered independently. A failed webhook does not block subsequent ones.

Delivery runs asynchronously on durable infrastructure — the webhooks are enqueued at response time and retried at the platform level if the initial attempt fails.

​

Configure webhooks on a mock rule

​

URL allowlisting

GoDizzy only sends outbound webhook requests to URLs on your organization’s allowlist. This prevents accidental callbacks to external production systems and limits the blast radius of a misconfigured rule. If you attempt to save a webhook URL that is not allowlisted, GoDizzy will reject the configuration with a validation error.

​

Template variables in webhooks

Webhook headers and body support the same template variables as mock response bodies. You can also reference top-level fields from the incoming request body using {{$reqBody['key']}}.

​

Example: simulate a payment webhook

Your agent calls POST /payments to initiate a payment. In production, the payment processor calls your webhook at https://your-service.example.com/webhooks/payments a few seconds later with a payment.completed event. Mock rule configuration:

• Method: POST
• Path: /payments
• Status: 200
• Body:
  {
    "payment_id": "{{$randomUUID}}",
    "status": "processing",
    "created_at": "{{$isoTimestamp}}"
  }
  

Webhook configuration:

• URL: https://your-service.example.com/webhooks/payments
• Method: POST
• Delay: 3000 ms (simulates the processor’s 3-second processing time)
• Headers:
  {
    "Content-Type": "application/json",
    "X-Webhook-Id": "{{$randomUUID}}",
    "X-Delivery-Timestamp": "{{$unixMs}}"
  }
  
• Body:
  {
    "event": "payment.completed",
    "payment_id": {{$reqBody['payment_id']}},
    "amount": {{$reqBody['amount']}},
    "currency": {{$reqBody['currency']}},
    "status": "succeeded",
    "completed_at": "{{$isoTimestamp}}",
    "idempotency_key": "{{$randomUUID}}"
  }
  

When your agent posts to the mock rule, it receives the 200 processing response immediately. Three seconds later, your webhook handler receives the payment.completed event — with fields echoed from the original request — exactly as it would from the real payment processor.

​

Example: simulate a multi-step job pipeline

Some APIs fire multiple webhooks as a job moves through stages. Use an ordered list of webhooks with increasing delays: GoDizzy fires each one after its configured delay, giving your handler a realistic sequence of state transitions to process.