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 | The shared views (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-uiandwebhooks-ui-wirekitwrite to the same destination, so publishing both would leave you with whichever ran last. Pick one explicitly.
webhooks-views already carries the whole view tree, 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.