Publishable tags

Tag	Publishes
webhooks	The umbrella: config, views and lang in one command — see below
webhooks-config	config/webhooks.php
webhooks-migrations	The Platform migrations — subscriptions + the delivery log
webhooks-client-migrations	The Client migration — webhook_calls
webhooks-server-migrations	The standalone-persistence migration — webhook_server_deliveries
webhooks-dashboard-migrations	The dashboard's hourly materialized view
webhooks-lang	The translation files (seven locales), to override a string or add another
webhooks-views	Every view except the operator console's two variants (including the webhooks::pagination control)
webhooks-dashboard-views	The observability dashboard's views
webhooks-self-service-views	The self-service portal's views
webhooks-ui	The operator console, neutral Tailwind variant
webhooks-ui-wirekit	The operator console, WireKit variant

The umbrella tag, and what it deliberately leaves out

php artisan vendor:publish --tag=webhooks

That publishes config, views and lang — everything you customize by editing a file.

It stops there on purpose, and the two omissions are the same two hazards the rest of this page describes:

• No migrations. A published migration runs. Sweeping the per-layer migration tags into an "everything" tag would create the client, server and dashboard tables in a host that never switched those layers on — undoing, in one command, the exact thing the per-layer split exists to prevent.
• Neither operator-console variant. webhooks-ui and webhooks-ui-wirekit write to the same destination, so publishing both would leave you with whichever ran last. Pick one explicitly. webhooks-views leaves both out as well: a published view always wins, so a neutral copy published with everything else would hold a WireKit console at the neutral rendering.

webhooks-views carries every other view directory, so the narrower webhooks-dashboard-views and webhooks-self-service-views tags are reachable through the umbrella's content without being listed separately.

One migration tag per layer

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.

Publishing is optional in the first place: left alone, every enabled layer registers its own migrations and php artisan migrate just runs them. To take them over instead, call ignoreMigrations() on that layer's provider — WebhooksServiceProvider, ServerServiceProvider, WebhookClientServiceProvider, WebhooksDashboardServiceProvider — from a service provider's register(). See installation.

The two operator-console variants are mutually exclusive

webhooks-ui and webhooks-ui-wirekit both land at resources/views/vendor/webhooks/livewire, so the second overwrites the first. Publish exactly one.

And for choosing a style you do not need either: webhooks.ui.variant picks the rendering at render time, with no copy to keep in step. A view published here still wins — see the operator console.

Publishing views is the escape hatch from WireKit

A host on another design system publishes the view tags and restyles them; the pagination control publishes with webhooks-views. See Styling the UI.