Skip to main content

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, no server.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/livewire and pushery/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 needs pushery/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.

When an update adds a migration and you manage them yourself, copy the new file from the package's database/migrations directory, or the layer's subdirectory, into your own under a current timestamp. Don't publish the tag again. With update_date_on_publish on in the migrations block of your config/database.php, which a Laravel 11 or later application has by default, vendor:publish looks for each file under the package's own name, doesn't find the copy it renamed the first time, and writes every migration of the layer a second time, so migrate stops at the first table that already exists. The changelog names the file whenever a release adds one.

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.