Webhooks Livewire Laravel Package

Product Decisions This Supports

• Feature framing: webhook self-service UI. This package is the presentation adapter — the Livewire components/views for managing webhook endpoints, subscriptions, and (likely) delivery visibility. It is not the webhook delivery engine. The product decision it informs is "how do we expose webhook configuration to users — admin console, customer-facing settings, or both — without building screens from scratch."
• Build vs. buy for the admin surface. Webhook management UIs are deceptively expensive: CRUD for endpoints, per-event subscription toggles, secret generation/rotation with one-time reveal, delivery log with retry/replay, and test-ping affordances. A drop-in Livewire adapter can compress that from a 2–4 week slice to a 2–5 day spike, if it matches your stack and tenancy model.
• Roadmap sequencing question. It lets you separate the domain capability (queuing, signing, retrying, dead-letter) from the presentation capability. That split is useful for sequencing: you can decide to ship the integration-capable backend first and defer the polished UI, or use this adapter to get a demoable surface early for design partners.
• Which persona gets webhooks first. Because the adapter ships opinionated screens, evaluating it forces the decision of whether webhooks are an internal ops tool (support needs to replay failures) or a customer-facing integration feature (developers need docs, keys, and logs). The former tolerates rough UI; the latter does not.
• Integration-ecosystem bets. If webhooks are on the roadmap as the first step toward Zapier/partner integrations or an event-bus product, an adapter that already models endpoint+event subscription gives you a vocabulary and a data shape to react to before committing.

When to Consider This Package

Consider it only when all of the following hold:

• You are already on Laravel + Livewire, and ideally already consuming the parent liberusoftware webhooks domain module — this adapter is meaningless (and unusable) standalone.
• The need is an internal or early-access admin surface, not a polished, documented, customer-facing developer portal.
• You have engineering capacity to read the source and fork. With 0 stars, 0 dependents, and no release history signal, there is effectively no community, no support channel, and no third-party usage to learn from. Treat the code as an example implementation you own from day one.
• Licensing is cleared. NOASSERTION means the repository does not declare a recognized OSI license. For a PM this is a hard gate, not a footnote: it blocks redistribution, may block use entirely under your legal policy, and will surface in any acquisition or security review. Get written clarification from the author before it touches a production dependency graph.
• The security-sensitive parts are yours: secret storage, one-time secret reveal, delivery-log retention, and tenant isolation should not be assumed correct in an unvetted adapter. Plan a review pass.
• You are comfortable with the release metadata being unverifiable — a last-release date of 2026-10-26 is in the future relative to normal packaging conventions, which is a signal to independently confirm tags, changelog, and that the published artifact matches the repo.

Look elsewhere (or build the screens in-house) when:

• You need a vendor-backed or SLA'd component, or you're in a regulated environment where unmaintained dependencies are disallowed.
• Webhooks are customer-facing and load-bearing for revenue — you need UX ownership, not an opinionated adapter.
• You are not on Livewire, or you're on a different tenancy/authorization model than the domain module assumes.
• The parent webhooks module itself is not yet adopted — in that case the adapter is a solution to a problem you don't have.
• You need delivery guarantees, retry semantics, and signing — those are domain-layer concerns and this package will not provide them.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free Laravel/Livewire UI adapter that gives us ready-made screens for managing webhooks — the plumbing customers and partners use to receive real-time events from our product. It could shave one to three weeks off an integration feature we'd otherwise hand-build, and it's cheap to trial because it's a thin presentation layer we can throw away. The reason to be cautious is provenance, not capability: it has zero adoption, no declared license, and no support, so I'd recommend a timeboxed two-to-five day technical spike to judge fit, with no production commitment until legal clears the license and engineering confirms we're already using the underlying webhooks module. Framed correctly, this is an accelerator and a reference design — not a strategic dependency.

To engineering (the short version): Presentation-only adapter for the liberusoftware webhooks domain module; assume no docs, read the source, fork it, and own it. Confirm (1) the Livewire version constraint, (2) which authorization/tenancy hooks the components expect, (3) whether secret handling and delivery-log views are safe to expose, and (4) the actual license text. Effort to evaluate: half a day to stand it up against a scratch app; a few days to judge whether the UX is worth keeping versus writing our own components against the same domain module.

Recommendation: Evaluate as a design reference with fork-in-hand, adopt only inside the Liberu ecosystem or behind a clearly-owned internal admin surface, and treat the missing license as the decision-blocking item rather than the low star count.