Use cases

Webhooks look like one HTTP request. Doing them safely takes many small parts that are each easy to get wrong: constant-time signature checks and secret rotation without downtime, refusing old or replayed messages, processing a retried message only once, keeping slow work out of the request, retrying a receiver that is down without flooding it when it comes back, keeping customer-supplied URLs away from your internal network, and a log that is useful but holds no secrets. Webhooks for Laravel ships all of them with safe defaults, for both directions and both kinds of team.

For teams that offer webhooks

• A webhooks feature for your customers — they add a URL and pick event types in your settings page; your code sends events as things happen, and they get signed messages, retries and a log you can show them.
• Marketplaces and e-commerce — orders, payments and shipping synced with partners, nothing sent when the transaction that triggered it rolls back.
• Recovery after a customer’s outage — the package retries for about a day; switch the endpoint back on and resend everything that failed with one call or one command.
• A page you can hand to your customers — how to receive and verify your webhooks, with tested code in PHP, Node, Python, Go and Ruby (see Guide for receivers).

For apps that consume webhooks

• Connect a payment or SaaS provider — create an inbound endpoint, paste its address and secret into the provider’s dashboard, and your handler runs once for every paid invoice or cancelled subscription, however often the provider retries.
• Many providers, one pipeline — payments, e-signature, CRM and source control go through the same verified, deduplicated, rate-limited receiving path; providers with their own signature format get a scheme of their own (webhooks:make-scheme github or stripe writes one into your app).
• Internal platforms — several services report events to each other with signed, logged deliveries.
• Rotate a leaked secret — rotate it; the old one keeps working for a day while the other side updates, then it stops.

Retries, waiting when the receiver asks, speed limits and auto-disable are the behaviour developers expect from hosted webhook-delivery services — here running inside your own app, on your own queue, with your data in your own database.

What it does not do: it ships no management routes or UI — only the inbound receiving route — so the screens your customers use are yours, built on the API and the JSON resources. It guarantees no ordering between deliveries to one endpoint (receivers order by the envelope’s timestamp). And it does not send through an egress proxy while the SSRF guard is on.