Webhooks Filament Laravel Package

Product Decisions This Supports

• Build vs. buy for webhook admin tooling. This package is a thin Filament presentation adapter over a webhooks domain module — it supplies admin-panel screens (endpoint/secret/delivery management) rather than webhook delivery logic itself. The real decision it informs is whether ops-facing webhook CRUD is worth engineering time or worth adopting as glue.
• Self-service vs. ops-managed webhooks. If webhook management is an internal support/ops workflow, an admin adapter is the right altitude. If it is a customer-facing capability (tenant-owned endpoints, customer-visible delivery logs, retry controls), this package is a starting point at best and a fork target at worst.
• Platform standardization. Adopting it implies committing to the Liberu module suite (module-webhooks + Filament adapter) as an internal platform layer. That is a roadmap decision with vendor-concentration consequences, not a one-off dependency choice.
• Roadmap sequencing for observability/ops surface. A drop-in admin UI can pull forward "webhook visibility" work that would otherwise wait behind API work — useful if support tickets about failed deliveries are a recurring cost.
• Feature-flag and containment planning. Because adoption risk is high and switching cost is low, this supports a decision to ship behind a flag with a thin internal interface, preserving a swap path to a custom screen or an alternate webhook backend.

When to Consider This Package

Consider it when:

• You are already on Laravel + Filament and already using (or willing to use) liberusoftware/module-webhooks; the adapter is only meaningful on top of that domain module.
• The need is internal admin/ops tooling with low blast radius — a screen support staff use, not a contractual customer surface.
• You want to validate a webhook workflow in days, with a credible plan to fork and own the presentation layer.
• You accept the maintenance burden: with 0 stars and 0 dependents, there is no community, no third-party issue history, and effectively a bus factor of one. Treat it as vendored source, not a dependency.

Look elsewhere when:

• License is unresolved. NOASSERTION means the terms are not machine-identifiable. Legal must clear it in writing before this ships in anything commercial, redistributed, or customer-facing. This is a hard gate, not a footnote.
• You need customer-facing webhook portals, per-tenant isolation guarantees, delivery retry/backoff policy, or observability dashboards beyond basic CRUD — you will be building that yourself regardless.
• You are not on Filament, or you use Nova/Backpack/custom Livewire; the adapter's entire value is the Filament binding.
• You are standardized on a different webhook core (native Laravel events, Spatie, Svix, Hookdeck); mixing cores creates two sources of truth for endpoint state.
• Release metadata is unreliable. The recorded last release (2026-10-26) post-dates the present, which signals either clock skew, pre-tagged/future-dated versions, or bad registry metadata. Verify actual tags and changelog before pinning.

Verdict: contained pilot, not strategic adoption. Value here is optionality and saved UI time, not capability.

How to Pitch It (Stakeholders)

For executives: This is admin-panel glue for webhook management — screens for support and ops to see and manage webhook endpoints and deliveries, sitting on top of an existing Laravel module. The bet is small: it saves us building CRUD screens ourselves, and if it disappoints we can replace the UI without touching webhook delivery. Two caveats to fund around it: the license is not clearly declared and must be cleared by legal before commercial use, and the project has no external users, so we own the maintenance. Recommendation: time-boxed internal pilot behind a feature flag, with a fork-and-own assumption from day one. Do not let it become load-bearing infrastructure.

For engineering: Treat this as vendored source, not a library. It is a Filament presentation layer only — domain logic, delivery, retries and persistence live in the underlying webhooks module, which is where your integration risk actually sits. Pin an exact commit, vendor it into the repo, and wrap access behind a thin internal service/interface plus a feature flag so the admin surface can be swapped for a first-party screen or a different webhook backend. Validate before committing: Filament and Laravel version compatibility, migration/publish behavior, authorization and tenancy handling on the resources (does it respect policies and tenant scoping out of the box?), and whether delivery logs are queryable at the volume you expect. Assume no upstream fixes; budget a small ongoing ownership cost and add smoke tests around the screens you actually use.