Filament Webhook Client Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. This package is a UI shell: it renders a Filament resource and policy over spatie/laravel-webhook-client's existing webhook_calls table. The honest build estimate for equivalent list/view screens, JSON formatting, translations, and an authorization policy is roughly 1–3 engineer-days plus ongoing maintenance. At MIT license and near-zero integration cost, this is a clear "buy" — the decision to make is not whether to build it, but whether your team is on Filament at all.
• Observability scope: who gets to see webhook traffic. The real product question this surfaces is access. Support, ops, and solutions engineers currently have to ask an engineer to query the database to answer "did we receive the webhook?" and "what did the payload actually say?" Shipping this turns a repeated engineering interrupt into a self-serve lookup. That's a support-cost decision with a measurable before/after (escalation volume, time-to-answer).
• Incident response posture for third-party integrations. During a partner outage or a payload-format change, the first question is always "what did they send us, and when?" This gives a browsable record of inbound calls in the same panel your team already uses, which shortens triage and reduces the temptation to add ad-hoc logging.
• Partner/vendor onboarding and integration QA. When adding a new webhook producer (payments, CRM, e-signature), QA and PM can verify deliveries land and inspect payload shape without a staging database session. This is a concrete accelerator for integration-heavy roadmap items.
• Roadmap boundary decision: this is internal tooling, not a product feature. It should not appear on a customer-facing roadmap or absorb product design time. Treat it as platform/admin surface owned by engineering, with the PM's role limited to approving who gets access and confirming the visibility requirement is met.
• Access-control and data-handling decisions you cannot skip. Webhook payloads routinely contain PII or secrets. The bundled policy defaults to view-list and view-record only — that default is a starting point, not a decision. Deciding which roles see which payloads, and whether you need to redact fields or restrict the resource to non-production panels, is a compliance input you own.
• Explicit non-goal: this is inbound-only visibility. It does not retry, replay, or guarantee delivery of anything, and it is not outbound webhook management. If a roadmap item depends on those capabilities, this package is not the answer and should not be scoped as if it were.

When to Consider This Package

Adopt when all of the following hold:

• You are already running Filament (v3, v4, or v5) as your admin panel. Without Filament, the package has no surface to render into and zero value.
• You already have spatie/laravel-webhook-client installed and receiving traffic. This plugin is explicitly a companion, not a replacement — it does not receive or store webhooks itself.
• Your stack is within the supported matrix (Laravel 12/13, PHP 8.5 supported in current releases). Pin the major version; the 3.x/1.x line is a separate, older track.
• The pain you are solving is human visibility: non-engineers asking engineers to look at the database, or slow incident triage. If the pain is "we need alerting" or "we need automatic retries," this is the wrong tool.
• You are comfortable treating a small, single-vendor package as forkable utility code. 11 stars and 0 dependents means effectively no ecosystem pressure-testing. The mitigation is that the surface area is tiny and the resource, model, and policy are all swappable via config — a fork is hours, not weeks.

Look elsewhere — or build — when:

• You are not on Filament, or your admin surface is something else (Nova, custom Livewire, Metabase). You would be adopting a framework to adopt a table.
• You need replay/retry/resubmission of failed webhooks, dead-letter handling, or backoff controls. The included policy is read-only by design; adding mutations means building your own resource anyway.
• You need monitoring and alerting (failure rates, latency, queue health, Slack/PagerDuty notification). That belongs in Horizon, Sentry, or a metrics pipeline.
• You need multi-tenant scoping, advanced filtering, or high-volume performance on the calls table. Small packages rarely anticipate your tenancy model; budget for a fork or custom resource.
• You need retention policy, export, or audit-grade compliance reporting. Nothing here addresses data lifecycle, and webhook payload retention is often the exact thing auditors ask about.
• You require a vendor SLA or maintained support contract. There is a security contact and an MIT license, but the project's release cadence is dominated by dependency bumps and framework-version compatibility — signals of a maintained-but-not-actively-developed package.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed add-on that gives our support and operations teams read-only visibility into inbound webhook traffic from our integration partners, inside the admin panel we already run. It replaces a recurring engineering interrupt — "can you check whether we got that webhook and what was in it?" — with a self-serve screen. Cost is effectively zero in license and under half a day of engineering to install and configure; there is no customer-facing change and no new infrastructure. The main judgment call is not technical but policy: who is allowed to see payload contents, since these can include customer data. We should decide that before rollout, not after.

For engineering: Two Composer packages deep: spatie/laravel-webhook-client (which you already have) and this plugin, which registers a WebhookCallResource and a read-only WebhookCallPolicy. Installation is one line in the panel's plugins() array after publishing the config; the resource class, model, policy, navigation sort, and icon are all overridable from config/filament-webhook-client.php, and translations are publishable. Version-pin it and treat it as forkable utility code — the upstream project is small (11 stars, no known dependents), its recent releases are mostly framework-compatibility and dependency bumps, and the entire integration surface is a handful of classes you could vendor in an afternoon if the project stalls. Before shipping to production: replace the default permissive policy with one scoped to your roles, restrict the resource to non-public panels, confirm your webhook_calls retention policy is compatible with exposing historical payloads, and be explicit that this is read-only — if anyone expects retry/replay, that is separate work.