Documentation
This guide explains how SnapWebhook works end-to-end: creating endpoints, sending requests, validating inputs, forwarding to your app, defining conditional responses, and understanding the generated endpoint templates. It reflects the features available in the platform.
Quick start
- Log in to the app dashboard.
- Create an endpoint and copy the short URL.
- Send any HTTP request (GET/POST/PUT/PATCH/DELETE, etc.) to that URL to capture it.
- Inspect the request in the dashboard: headers, query params, body, and response.
- Optionally enable pass-through to forward the request to your own service while still capturing it.
Endpoints
Endpoints are where incoming webhook requests are captured. In the app you can create endpoints and configure settings. Key fields from the form:
- Name — a human-friendly label to identify the endpoint.
- Allowed Methods — restrict allowed HTTP methods (leave empty to allow all).
- Allowed IPs — IP allowlist (leave empty to allow all).
- Validation Conditions — rules that must all pass before a request is considered valid.
- Pass-through — when enabled, requests are forwarded to a destination URL you control.
- Conditional Responses — return different response bodies based on request content.
Short subdomain routing
Each endpoint provides a convenient “short domain” in the form your-slug.webar.ch. You can send requests to that subdomain with any path and method, and they’ll be captured by your endpoint.
- Example:
https://acme-demo.webar.ch/orders/created
- All HTTP methods are supported (GET, POST, PUT, PATCH, DELETE, etc.).
- You can also use a long-form URL if provided in your dashboard.
Access & validation
You can control access using:
- Allowed Methods — if set, only listed HTTP methods are permitted.
- Allowed IPs — if set, only requests from these IPs/CIDRs are permitted.
Additionally, Validation Conditions let you assert specifics of the request. From the form schema, each row includes:
- Type — where to look (header, query, body).
- Condition — equals, not_equals, contains, not_contains, etc.
- Parameter — header name, query key, or body path (supports dot-notation like
event_data.to
). - Value — the value to compare against.
All validation conditions must pass for the request to be accepted. Otherwise, the request can be rejected or handled as invalid per your controller logic.
Pass-through (forwarding)
Enable Pass-through to forward incoming requests to a destination URL while still capturing them in SnapWebhook. This is useful for monitoring production webhooks without disrupting your services.
- Enable Pass-through — toggles forwarding on/off.
- Destination URL — the URL to forward the original request to.
Conditional responses
You can return different response bodies depending on conditions, evaluated from top to bottom; the first match is returned. Each row defines:
- Type — header, query, body, or
default
. - Condition — equals, not_equals, contains, not_contains (for header/query/body types).
- Parameter — if using header/query/body types, the key/path to inspect.
- Value — the target value to match.
- Return as — text or json.
- Return — the actual response value or JSON.
A row with type = default
acts as a fallback and doesn’t require a parameter or value.
Endpoint templates (schema)
When requests arrive, a background process automatically builds and evolves a schema (template) for the endpoint, per method and path. It analyzes headers and body to infer types like string
, number
, boolean
, null
, arrays (e.g., string[]
), and nested object structures. These templates help you understand the shape of incoming payloads.
Key behaviors:
- Header schema — maps header names (lowercased) to
string
. - Body schema — infers primitive types, nested objects, lists of primitives, and arrays of objects using a
__arrayOf
convention. - Merging — subsequent requests merge into the existing schema, unioning primitive types (e.g.,
string|number
) and merging nested object keys. - Samples — a
sample_count
increments each time a matching request is processed.
Examples
cURL
curl -X POST "https://subdomain.webar.ch" \
-H "Content-Type: application/json" \
-H "X-Webhook-Secret: your-secret-token" \
-d '{
"event": "payment.completed",
"payment_id": "pay_12345",
"amount": 2999,
"currency": "USD"
}'
PHP
$webhookData = [
'event' => 'payment.completed',
'payment_id' => 'pay_12345',
'amount' => 2999,
'currency' => 'USD',
];
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'https://subdomain.webar.ch');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($webhookData));
curl_setopt($ch, CURLOPT_HTTPHEADER, [
'Content-Type: application/json',
'X-Webhook-Secret: your-secret-token',
]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
echo "Webhook sent with status: " . $httpCode;
Conditional response matrix
Type | Condition | Parameter | Value | Return as | Return |
---|---|---|---|---|---|
header | equals | X-Mode | debug | json | {"debug": true} |
query | equals | status | ok | text | OK |
default | — | — | — | json | {"status":"received"} |
The first matching row wins; include a default row as a fallback.
FAQ
Do I need an account?
Yes, you need an account to create endpoints and access the dashboard.
Is pass-through safe for production?
Yes. Requests are captured then forwarded to your destination. Be mindful of rate limits and secure your destination URL.
How are schemas generated?
A background job infers schemas from your request logs, merging types and nesting across samples.