Webhooks Livewire Laravel Package

Getting Started

This package is a presentation adapter: it wires the liberusoftware/webhooks domain module into Livewire components (typically a webhook CRUD screen plus a delivery-attempt log). Treat it as UI glue, not as the source of truth for webhook behaviour.

Minimal steps:

1. Install alongside the domain module, not on its own. The Livewire components expect the core webhooks service classes, migrations, and event/job infrastructure to already exist:

   composer require liberusoftware/webhooks liberusoftware/webhooks-livewire
   

2. Publish and run migrations. Check both packages — the core module owns the webhooks and delivery/log tables; this adapter should not define schema, but verify with php artisan vendor:publish --tag=webhooks-livewire (tag names may differ; inspect src/Providers).
3. Confirm Livewire is registered. The service provider registers components under a namespace (commonly webhooks:: or liberusoftware.webhooks.). Find the exact alias in the provider's Livewire::component(...) calls before writing routes.
4. Mount a page. Drop a single component into an existing authenticated route — the adapter is designed to be embedded, not to own your routing:

   <livewire:webhooks.webhook-list />
   

5. First use case: list existing webhooks, open one, trigger a "send test payload" action, and watch the delivery history refresh. That end-to-end loop is the fastest way to validate that the adapter, the core dispatcher, and your queue worker are all talking to each other.

Where to look first: the Livewire/ (or Components/) directory for the public action methods, then the service provider for route/alias registration. Ignore the views until the components render.

Implementation Patterns

Keep domain logic out of the components. The value of this adapter is that it does not contain delivery logic. When you need custom behaviour (retry policy, custom signing header, filtering which events are exposable), extend the core module's service/contract and let the Livewire component inject it — do not add methods on the component.

Embed-per-resource. The natural pattern in a modular Liberu app is to mount the webhook components inside each resource that can emit events (an Order page gets a webhook tab, a Contact page gets one). Pass the model as a typed Livewire property and let the component scope its own queries:

<livewire:webhooks.webhook-manager :model="$order" />

If the component doesn't already accept a scoping model, this is the first place to add a small wrapper rather than forking the package.

Action methods as the integration seam. The public Livewire methods (save, delete, sendTest, rotateSecret) are your integration points. Prefer calling them via Livewire::test() in feature tests over re-implementing the flow — you get coverage of the domain module's real code paths for free.

Delivery-log polling. Most webhook UIs want a live-ish delivery log. Two working patterns:

• wire:poll.10s on the log component for low-traffic tenants — simplest, no extra infrastructure.
• Broadcast on the core module's WebhookDelivered/WebhookFailed events and #[On('echo-private:...')] in the component for anything busier. Use the core module's events rather than listening to your own queue events; the adapter is meant to be event-agnostic.

Secret handling. Show the signing secret once on creation, then store it write-only in the UI (a masked display with a "rotate" action). Never bind the raw secret to a public Livewire property that persists across requests — Livewire serializes public properties into the payload.

Composition with your own policy layer. Gate the components with your existing WebhookPolicy (authorize create/update/delete against the tenant) instead of assuming the adapter does it. Zero-star, zero-dependent packages rarely ship multi-tenant authorization.

Gotchas and Tips

• License is NOASSERTION. That is not a permissive license, it means the repository's metadata didn't resolve to a recognised SPDX identifier. Before shipping this in a commercial product, read the actual LICENSE file and get a human to sign off. This is the single biggest risk with the package and is easy to overlook because Composer won't warn you.
• Zero stars / zero dependents / stale-looking release date (release date is in the future relative to normal chronology, suggesting a synthetic or auto-generated repo). Treat every version as unvetted: pin an exact version, vendor-lock it, and read the diff before upgrading. Assume no upstream bug fixes are coming, and be prepared to fork into app/ or a local path repository.
• The adapter is coupled to the core module's version. If a component breaks after a core upgrade, the failure is usually a renamed method on a service class, not a Livewire problem. Check composer why liberusoftware/webhooks first.
• wire:model on relationships will bite you. If the component binds a webhook.events array, edits to that array in the UI may not persist until the core module's save is called with the full payload. Debug by dumping the component state in a Livewire::test() rather than clicking through the browser.
• Queue dependency for "send test". A test send enqueues a job. If QUEUE_CONNECTION=sync in local dev it appears instant and you'll miss a broken worker in staging; if it's redis and the worker is down, the button silently does nothing. Check failed_jobs and the delivery log before blaming the UI.
• Namespace collisions. Livewire component aliases from modular packages often shadow each other (webhooks. vs webhooks::). If <livewire:...> renders a blank div, Livewire::getClass() for that alias is the fastest diagnostic.
• Extension points are thin, by design. Rather than subclassing components, wrap them in your own Blade partial or a thin Livewire parent that renders the package component as a child, and pass configuration through public properties. Forking the package for a one-line UI change is a maintenance trap given the apparent project health.
• CSRF/signature testing. When you build a receiver to test against, remember the core module likely signs with a timestamp header; replaying a captured request after the tolerance window will legitimately fail verification. Not a bug in the adapter — a common false alarm during debugging.