Installation
Requirements
- PHP 8.4+ with
ext-curl,ext-json,ext-sodium - Laravel 13+
- A database — for the layers that persist. The Platform, Client, Dashboard and
standalone-persistence layers store their tables in PostgreSQL 13+ or MySQL 8.4+. A
send-only app (
platform.enabled=false, noserver.persistence) runs no migrations at all and needs no database — see Send-only setup. - A queue worker for outbound delivery (Redis recommended so retry backoff never blocks other work)
- The dashboard and the self-service portal additionally need
livewire/livewireandpushery/wirekit— see Styling the UI - The operator console needs only
livewire/livewire: its shipped views are neutral Tailwind and use no design system. The WireKit variant (--tag=webhooks-ui-wirekit) is the one that needspushery/wirekit
Which engine to reach for, and what the difference actually costs you, is its own page: Choosing your database.
Install
composer require pushery/webhooks-for-laravel
Publish the config and migrations, then migrate:
php artisan vendor:publish --tag=webhooks-config
php artisan vendor:publish --tag=webhooks-migrations
php artisan migrate
webhooks-migrations publishes the Platform migrations (the subscriptions table and the
delivery log). Each other layer has its own tag — webhooks-client-migrations,
webhooks-server-migrations, webhooks-dashboard-migrations — so you only ever migrate the
layers you switched on; see Publishable tags.
Publishing is optional: left alone, every enabled layer registers its own migrations and
php artisan migrate just runs them.
To publish and manage them yourself instead, call ignoreMigrations() on that layer's provider
from a service provider's register() — there is one per layer, and each switches off only its
own:
Pushery\Webhooks\WebhooksServiceProvider::ignoreMigrations();
Pushery\Webhooks\Server\ServerServiceProvider::ignoreMigrations();
Pushery\Webhooks\Client\WebhookClientServiceProvider::ignoreMigrations();
Pushery\Webhooks\Dashboard\WebhooksDashboardServiceProvider::ignoreMigrations();
There is one migration tag per layer, and each publishes its files flat into
database/migrations — where the migrator actually looks. Publish only the layers you
switched on: a published migration runs, so publishing all of them would create tables for
layers you never enabled.
The UI layers need two more packages
The dashboard and the
self-service portal are Livewire components built from WireKit
design-system components. If you plan to use either, install both packages first; without them a
shipped view fails with Unable to locate a class or view for component [wirekit::card]:
composer require livewire/livewire pushery/wirekit
The operator console is the exception, and it is a real one rather
than a footnote: its shipped views are neutral Tailwind with no WireKit component in them, so it
needs livewire/livewire and nothing else. Installing pushery/wirekit for it buys nothing and
narrows your Composer resolution with this package's conflict constraint on it. There is a
WireKit variant of the console, published with --tag=webhooks-ui-wirekit, and that one needs
the package — but it is a choice you make later, not a prerequisite of using the console.
A host on a different UI kit instead publishes the views and restyles them (see Publishable tags and Styling the UI). Sending and receiving need neither package.
Verify the install
php artisan webhooks:preflight checks that the database the persistent layers store their
tables in is supported, and prints the connection it resolved. See the
command reference.
If your app uses Laravel Boost
The package bundles a Boost skill. Boost picks it up from the installed package with no setup, and it gives an agent working in your app the layer gates, the per-layer publish tags and the smallest correct send and receive setup — so it reaches for the right switch instead of inferring one. There is nothing to publish and nothing to configure; if you do not use Boost, the file is inert.