Filament Webhook Client Laravel Package

Technical Evaluation

Architecture fit. This package is a thin, single-purpose UI adapter: it contributes a WebhookCallResource, a WebhookCallPolicy, translations, and a small config surface to a Filament panel, rendering rows from Spatie\WebhookClient\Models\WebhookCall. It is not infrastructure — it owns no persistence, no transport, no queue logic. That narrowness is its main architectural virtue: the entire webhook receive/store/process pipeline remains Spatie's, and this package only adds a read-oriented admin view. For any team already running Filament 3/4/5 plus spatie/laravel-webhook-client, the fit is near-perfect and the integration surface is a single ->plugins([...]) entry in the panel provider. For a team without Filament, the package is irrelevant — it cannot be consumed standalone, so it should not be evaluated as a webhook-observability tool in general.

Integration feasibility. Low effort, low ceremony. Prerequisites are hard: Spatie Webhook Client must already be installed, configured, and receiving calls into webhook_calls before this package has anything to show. Install is composer require tapp/filament-webhook-client:"^4.0", one optional config publish, one plugin registration line. Version compatibility is explicitly documented as a matrix (Filament 4.x/5.x → package 4.x; Filament 3.x → package 1.x), which is the single most important fact for the integration decision — it means the package is viable on both legacy and current Filament, but the major version you install is dictated by your Filament version, not your preference.

Technical risk. The dominant risk is stewardship, not engineering. Eleven stars, zero dependents, and a changelog dominated by Dependabot bumps and CI housekeeping indicate a small-team, low-adoption project. The code footprint is small and the license is MIT, so the abandonment scenario is cheap to absorb: fork the resource and policy into app/Filament/ and drop the dependency. Note also the release hygiene signal — the listed last release (2026-07-04) sits ahead of the current date, so confirm the actual tagged version and diff against the 4.x branch before pinning. Secondary risks: the policy defaults to broad view access (anyone who can reach the panel can read webhook payloads, which frequently contain PII or provider secrets) and the package reads whatever is in webhook_calls, so retention/size of that table becomes a UI performance concern.

Key questions.

• Which Filament major are we on, and therefore which package major (1.x vs 4.x) is the only valid target?
• Has Spatie Webhook Client's webhook_calls table been in production long enough to have data, or is this speculative?
• Who should see webhook payloads — do we need a custom policy before shipping, and do payloads contain PII/tokens requiring redaction?
• Is the model binding via config (models.webhook-call) sufficient for our setup, or do we use a custom WebhookCall model?
• What is our exit cost if the package stalls — can we vendor the resource into our own codebase in under a day?

Integration Approach

Stack fit. Requires Laravel + Filament + spatie/laravel-webhook-client, with the compatibility matrix as the binding constraint: Filament 4.x/5.x pairs with package 4.x; Filament 3.x pairs with package 1.x (the README explicitly points 3.x users to the 1.x docs tree). PHP 8.5 and Laravel 13 support are present in recent 4.1.x tags, so the package tracks current framework lines rather than lagging. Config keys resources, models, and policies are all overridable, so a team can substitute its own resource class or policy without forking — that is the correct extension mechanism and should be used in preference to editing vendor code.

Migration path. Greenfield: install Spatie Webhook Client first, verify calls land in webhook_calls, then add this package. Brownfield: identify the Filament major, pin the matching package major, publish config, register the plugin in the panel provider, and only then decide whether the default policy is acceptable. There is no data migration — the package adds no tables or columns. If we later drop it, removal is composer remove plus deleting the plugin line; no schema rollback.

Compatibility. Two real constraints. First, the pin is derived from Filament, so a Filament 3→4 upgrade is a package 1.x→4.x jump and should be scheduled with that upgrade, not independently. Second, the model binding assumes the standard Spatie WebhookCall model; teams with a custom model must wire it through models.webhook-call or they will silently view the wrong table.

Sequencing.

1. Confirm Filament major and select package major accordingly.
2. Verify Spatie Webhook Client is installed, configured, and writing calls.
3. composer require, publish config, publish translations if non-English UI is needed.
4. Register FilamentWebhookClientPlugin::make() in the panel provider; assign navigation sort/icon to fit existing menu.
5. Replace the default policy with a project-owned policy gating view access to an appropriate role — do this before exposing the resource to non-admins.
6. Smoke-test: trigger a real webhook, confirm it appears in the list and the detail view renders formatted JSON correctly.
7. Document the retention policy for webhook_calls in the same PR.

Operational Impact

Maintenance. Minimal code to maintain, but the dependency sits at the end of a three-link chain (package → Spatie Webhook Client → Filament) and inherits the volatility of all three. The practical mitigation is to treat this as a disposable, forkable UI layer: budget roughly a day to vendor the resource and policy if the upstream project goes quiet, and keep that option documented. Because the extension points are config-driven, day-to-day customization should never require touching vendor files.

Support. Support comes from a small vendor (Tapp Network) with a public security contact and an MIT license — no SLA, no commercial backing implied. Internal ownership should therefore be assigned explicitly to whoever owns the Filament panel. Expect to self-serve on issues; the README is adequate for installation but thin on customization beyond the policy override.

Scaling. The UI reads directly from webhook_calls, so list performance degrades as the table grows — webhook tables accumulate fast and are rarely pruned. Enforce a retention window (prune by age or volume) or the admin resource becomes a slow page and a database liability. There is no pagination-independent search strategy documented; if volume is high, plan to constrain the default table query or archive old calls. The package adds no runtime overhead to webhook receipt itself — it is purely a read path, so it cannot degrade the ingestion pipeline.

Failure modes.

• Filament major mismatch — installing 4.x on Filament 3 (or 1.x on Filament 4) breaks the panel; this is the most likely failure and is entirely preventable via the documented matrix.
• Spatie not installed/configured — plugin registers but the resource errors or shows nothing; the README flags this as a hard prerequisite.
• Unpruned table — slow list views and a bloated database; an operational, not code, failure.
• Over-permissive default policy — unauthorized panel users read webhook payloads containing PII or provider tokens; a security failure with a one-line fix that is easy to forget.
• Upstream abandonment — no immediate breakage, but security patches for the Filament/Spatie chain stop flowing through this package; mitigated by the fork path.
• Custom model not wired — resource silently reads the default model and displays an empty or wrong dataset.

Ramp-up. Near-zero for a Laravel/Filament developer: one composer command, one config publish, one plugin line. The only genuine learning is the policy surface and the Filament-version mapping, both documented. Realistic estimate is well under a day including smoke testing and a policy override — provided Spatie Webhook Client is already live. If it is not, that prerequisite, not this package, is the actual work.