Skip to main content
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.
Webhook delivery is asynchronous. Your caller receives the mock response before any webhooks are dispatched. Do not rely on webhook delivery completing within a specific wall-clock window relative to the mock response.

​
Configure webhooks on a mock rule

1

Open the mock rule editor

Navigate to your route collection, open the routing rule you want to attach webhooks to, and ensure the action is set to Mock.
2

Add a webhook

In the Webhooks section of the rule editor, click Add Webhook. Each webhook has the following fields:
FieldDescription
URLThe endpoint GoDizzy will POST to. Must be on an allowlisted domain.
MethodThe HTTP method (e.g., POST, PUT).
HeadersA JSON object of request headers to include with the callback. Supports templates.
BodyThe payload to send. Supports templates referencing the incoming request body.
Delay (ms)How long GoDizzy waits before sending this specific webhook, in milliseconds.
3

Set the delay

The delay is per-webhook, not global. Use it to simulate the realistic gap between your mock response and the callback a real API would send. For a payment processor that typically calls back within 2–5 seconds, set the delay to somewhere in that range.
4

Add more webhooks (optional)

Click Add Webhook again to add a second callback. GoDizzy fires them in the order listed. You can reorder them by dragging.
5

Save the rule

Click Save. Webhooks take effect immediately for all subsequent requests that match this 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.
Add your local development server, your staging webhook receiver, or your internal test endpoint to the allowlist before configuring webhooks. Contact your organization admin or check your account settings to manage the allowlist.

​
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']}}.
SyntaxAvailable inDescription
{{$randomUUID}}Body, headersNew UUID per delivery
{{$isoTimestamp}}Body, headersUTC timestamp at delivery time
{{$unixSeconds}}Body, headersUnix epoch seconds
{{$unixMs}}Body, headersUnix epoch milliseconds
{{$date}}Body, headersYYYY-MM-DD in UTC
{{$randomInt(a,b)}}Body, headersRandom integer in range
{{$randomAlphaNumeric(n)}}Body, headersRandom alphanumeric string
{{$randomHex(n)}}Body, headersRandom hex string
{{$reqBody['key']}}Body onlyTop-level field from the incoming request JSON body

​
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:
#URLDelayEvent
1https://your-service.example.com/webhooks/jobs1000 msjob.queued
2https://your-service.example.com/webhooks/jobs4000 msjob.running
3https://your-service.example.com/webhooks/jobs9000 msjob.completed
GoDizzy fires each one after its configured delay, giving your handler a realistic sequence of state transitions to process.