SSRF protection
Webhook targets are restricted to public HTTPS destinations. Localhost, private networks, link-local ranges, and cloud metadata endpoints are blocked.
Security and reliability
A safer way to schedule user-defined webhook deliveries.
Webhook Scheduler is built around a simple rule: user-provided webhook URLs are untrusted until they pass validation, dispatch safety checks, and plan-based limits.
API request
HTTPS onlytarget_url:
require https
block localhost and private networks
block cloud metadata endpoints
revalidate before dispatch
do not follow redirects automatically
delivery:
atomic worker claim
bounded timeout
capped retries by plan
response body truncation
retained logs by planBounded delivery
Payload size, headers, timeout, retry attempts, monthly quota, and log retention are limited by plan to protect reliability and margin.
Operational visibility
Every scheduled job can be inspected through status, attempts, response code, latency, response body, and retry state.
Target URL safety
Webhook Scheduler only dispatches to public HTTPS endpoints. Targets such as localhost, private IP ranges, link-local networks, and cloud metadata services are rejected. The dispatcher also revalidates targets before execution so a job is not trusted only because it looked safe when it was created.
Redirects are not followed automatically. If a target returns a 3xx response, that response is recorded as the delivery outcome instead of silently sending traffic to a new destination.
API keys and dashboard access
Public scheduling endpoints require an API key created from the authenticated dashboard. API keys should be stored in backend environment variables or trusted automation tools, not shipped to browsers.
Dashboard routes require account authentication. The dashboard exposes job history, delivery attempts, API keys, quota usage, and billing controls only for the current workspace.
Retry and worker reliability
Failed deliveries can retry with plan-based caps and backoff. Each attempt is recorded with status, latency, error, response body when available, and final delivery state.
Worker execution uses an atomic claim before dispatch. That protects against duplicate processing when a job is due and more than one execution path could otherwise see it.
Cost and abuse controls
Webhook scheduling can become expensive if one customer sends oversized payloads, retries against a dead endpoint, or retains logs forever. Webhook Scheduler keeps those costs bounded with payload limits, header limits, response truncation, timeout caps, retry caps, quotas, rate limits, and retention windows.
The public plan limits are described in the fair use policy. For volume-sensitive workloads, use custom volume review instead of assuming unlimited traffic.
What Webhook Scheduler does not promise
This page describes product safeguards, not a contractual SLA. The product does not promise unlimited jobs, unlimited log retention, dedicated Slack support, or delivery to unsafe networks.
If you are designing a mission-critical integration, combine scheduled webhooks with receiver-side idempotency, monitoring, and a clear fallback path for customer-impacting workflows.
FAQ
Does Webhook Scheduler allow private network targets?
No. Webhook targets must be public HTTPS endpoints. Localhost, private networks, link-local ranges, and metadata endpoints are blocked.
Are redirects followed during webhook delivery?
No. Redirect responses are recorded as the result instead of automatically following them to another destination.
Are webhook retries unlimited?
No. Retry attempts are capped by plan so delivery can recover from temporary failures without unbounded cost or receiver pressure.
Where can I see delivery evidence?
The dashboard shows job status, attempts, status codes, latency, errors, response body snippets, payload context, and retry state.
Ship delayed webhooks without maintaining queue infrastructure.
Start with the free plan, test a real delivery, then upgrade when the workflow becomes production critical.
Schedule a test webhook