Webhooks for Laravel

An all-in-one, config-gated webhooks toolkit for Laravel. It sends signed outbound webhooks, receives and verifies inbound ones, gives your customers a self-service portal to manage their own endpoints, and puts an observability dashboard over the whole delivery log — and you switch on only the layers you need.

Signatures are Standard Webhooks by default, so every delivery is verifiable out of the box by any Standard Webhooks consumer in any language. The engine is entirely in-house — no third-party webhook-engine dependency — and its storage runs on PostgreSQL or MySQL 8.4+ (or on no database at all, if you only send).

composer require pushery/webhooks-for-laravel

The layered architecture

The package is four layers on a shared crypto/transport core — the core is the first row of the table below, not a sixth thing beside it. Each layer above the core has a single switch, so you pay only for what you turn on; the core has none, because everything runs through it. Configure only what you need.

Layer	What it does	Gate
Core	Signing dialects, the SSRF guard, and the HTTP transport shared by everything	Always on
Server	The outbound delivery engine — sign, queue, retry, back off	On by default (server)
Platform	Endpoint subscriptions + event fan-out, the self-service portal, health scoring, payload transforms, egress allowlist, AsyncAPI export	On by default (platform); each sub-feature opt-in
Client	Inbound receiving — verify, de-duplicate, store and queue incoming webhooks	Opt-in (client.enabled, default false)
Dashboard	A customer-facing observability UI over the delivery log	Opt-in (dashboard.enabled) and not auto-registered

Sending and the platform management layer work as soon as the package is installed. Receiving, the self-service portal, endpoint health scoring, payload transforms, the dashboard, Laravel Pulse, Scout search, OpenTelemetry, canonical-JSON signing, Ed25519 signing, the egress proxy, and standalone delivery persistence are each individually opt-in and off until you enable them.

Two dependencies between the gates

The switches are not fully independent, and both exceptions bite silently if you do not know them.

• Platform implies Server. Fan-out delivers through the Server engine, so platform.enabled=true boots the Server layer regardless of server.enabled. Setting WEBHOOKS_SERVER_ENABLED=false on its own therefore changes nothing — to stop outbound delivery entirely, set both to false.
• Dashboard requires Platform. The dashboard reads Platform's webhook_deliveries log, whose migration only runs while platform.enabled=true. A dashboard without the Platform layer has no table to read (unless you point dashboard.source_model at a delivery-log model you own).

Where to go next

Start here:

• Installation — requirements, the publish tags, and the packages the UI layers cannot render without
• Quickstart — send a signed webhook, receive and verify one, or run send-only with no database at all
• Choosing your database — the three topologies, what PostgreSQL buys you over MySQL (cost, never correctness), and the one collation trap that costs data

Then the layer you actually need:

• Sending — the PendingWebhook builder, secret rotation, backoff, timeouts, mutual TLS and the proxy
• Receiving — the inbound pipeline, the per-source config, the shipped verification adapters
• Subscriptions and fan-out — endpoints, event fan-out, health scoring, payload transforms, the published egress IPs and AsyncAPI export
• The self-service portal — the customer-facing endpoint screens
• The dashboard — the observability UI, operator mode, and the JSON metrics endpoint
• The operator console — the two unscoped components for the screens you run

Cross-cutting:

• Signatures and interop — the wire format, every shipped scheme, and the published known-answer vectors
• Events — the two event families, and which one a send-only app gets
• Security — the SSRF guard, what is encrypted, what is redacted
• Reliability — retries, idempotency, the circuit breaker, rate limiting and retention
• Reference — configuration, commands, publish tags, the supported public API, and the status values and exceptions you read out of the tables