Skip to main content

Documentation Index

Fetch the complete documentation index at: https://supahooks.ar27111994.dev/llms.txt

Use this file to discover all available pages before exploring further.

The mocking settings control what your webhook endpoint returns to the sender. Use them to simulate specific scenarios — a slow callback, a queued-acceptance response, a 503 during a provider outage — without needing a real downstream service to produce those conditions.

​
What you can simulate

  • Custom error responses: return 4xx or 5xx status codes to test how your client handles retries and failure paths
  • Slow callbacks: add artificial response delay to verify that your client respects timeouts correctly
  • Structured bodies: return JSON, XML, or plain text with any headers, matching the shape your client expects

​
Response settings

​
defaultResponseCode
integer
default:"200"
HTTP status code returned to every sender. Accepted range: 100–599.
​
defaultResponseBody
string
Body returned to the sender. Accepts JSON, XML, or plain text strings.
​
defaultResponseHeaders
object
Key-value pairs of headers to include in every webhook response. For example:
{
  "Content-Type": "application/json",
  "X-Debug-Source": "webhook-debugger"
}
​
responseDelayMs
integer
default:"0"
Artificial delay added after processing completes, in milliseconds. Accepted range: 0–10,000. Values above 10,000 ms are clamped. This delay is applied after processingTime is measured, so it does not affect the stored processingTime value in your logs.

​
Example: slow 202 acceptance

This configuration returns a 202 Accepted response after a 1.5-second delay, which is useful for testing clients that send and poll separately: 
{
  "defaultResponseCode": 202,
  "defaultResponseBody": "{\"received\":true}",
  "responseDelayMs": 1500
}
The processingTime field in captured log events reflects actual server-side processing time only. It excludes the responseDelayMs delay, so your latency measurements are not skewed by the simulated slowness.

​
Overriding the response status per request

To force a different status code for a single request without changing the global setting, add __status as a query parameter on the webhook URL: 
curl "https://<run-id>.runs.apify.net/webhook/wh_demo123?__status=503"
This is useful for testing specific error scenarios mid-session without restarting the actor.

​
Custom script overrides

If you have a customScript configured, the script can also modify the response status, body, or headers before they are sent. Script-level overrides take precedence over the default response settings. See the custom scripting documentation for details.