Nova Webhooks Laravel Package

Product Decisions This Supports

• Build vs. buy for integration admin. The core value is not webhook delivery — that's commodity — it's the Nova CRUD surface, event subscription picker, and delivery log viewer. That's roughly the scope of a small internal admin project we would otherwise staff. Buying it converts a build item into a configuration item.
• Roadmap: making "integrations" a shipping feature instead of a project. Customer-facing or partner-facing webhooks are usually a recurring ask that sits in the backlog because each one implies custom code. This package turns that into: enable the tool, define subscriptions, document the payload contract. It is a candidate to absorb a class of integration requests without a dedicated epic.
• Moving operational changes out of the release train. Active/inactive toggles and endpoint edits in an admin UI mean support and solutions engineers can fix a broken customer integration without an engineering deploy. That is a real reduction in cycle time for a recurring support category.
• Support load reduction via delivery logs. "Your webhook didn't fire" is expensive to triage blind. Persisted payload history and delivery status make it a self-serve or tier-1 question. Worth instrumenting the ticket tag before/after so we can prove it.
• Segmenting integrations by environment and tenant. One subscription per external system per environment is the sane default; the package supports the inventory without us inventing a schema. This is what lets enterprise customers get dedicated endpoints without a fork.
• Decisions this should not be used to support: promising delivery SLAs, exactly-once semantics, or guaranteed ordering. The sources don't establish at-least-once vs. at-most-once, idempotency keys, or backoff behavior. Do not let a sales conversation get ahead of what we've verified.

When to Consider This Package

Adopt when all of these are true:

• We are already running Laravel Nova. Nova is a licensing and tooling decision that must stand on its own — do not buy a Nova license as a side effect of wanting webhooks.
• We have a durable queue with real workers (Redis + Horizon, or SQS). Sync-queue operation defeats the purpose and turns third-party latency into user-facing latency.
• We need visibility and configurability more than throughput: a modest number of endpoints, human-managed, where the admin UI and logs are the point.
• The team is fluent in Laravel. The install is trivial; the consumer-side work (signature verification, retry tolerance) is the actual cost and is routinely underestimated.
• We can keep the integration thin — no business logic inside the package's extension points — so it stays replaceable.

Look elsewhere when any of these are true:

• No Nova in the stack. The marginal value collapses to a dispatcher we could get from spatie/laravel-webhook-server with no license cost.
• Delivery guarantees are a product requirement. If we need documented idempotency keys, dead-letter handling, replay, and per-endpoint delivery dashboards, this package's support posture (0 stars, unknown maintainer count, no visible security disclosure process) is not a foundation for that promise.
• High fan-out volume. One internal event with N subscriptions is N outbound requests and N log rows. Without confirmed log retention/pruning, storage cost becomes the dominant line item.
• We already have an in-house dispatcher or Spatie installed. The delta is only the UI and logs; pay for it deliberately or not at all.
• We are pinned to opscale-co/actions v3, or in an environment requiring vendor security review, procurement sign-off, or contractual support.
• SSRF exposure is unacceptable. If untrusted users could ever reach the endpoint configuration screen, we need an allowlist and egress controls this package doesn't advertise.

Adoption gates before any commitment:

1. 15-minute fact check: diff composer.json between v1.1.0 and v1.2.0. v1.2.0's only change is adopting opscale-co/actions v4 — a transitive major bump inside a minor release. Read the manifests rather than trusting the changelog, and confirm whether PHP/Laravel/Nova floors moved.
2. 1–2 day spike in a non-production branch against a request-capture receiver: verify headers, signature scheme, HMAC algorithm, timestamp/replay handling, retry/backoff shape, and log persistence.
3. One sprint to production-hardened: queue-lag and failure-rate monitoring, dead-letter/runbook, secret rotation procedure with a dual-secret window, and a consumer-facing integration guide.
4. Pin exact versions; do not auto-merge Dependabot PRs on this package.

How to Pitch It (Stakeholders)

To executives: We have a recurring class of "can you send us an event when X happens" requests that currently each become an engineering project. This package gives us a configurable webhook integration surface — endpoint management, event subscriptions, and delivery history — for roughly 1–2 engineer-days of setup plus about a sprint of hardening. It moves routine integration changes off the release train and turns a category of support tickets into self-serve diagnosis. The honest caveats: it requires Nova (free if we already own it, not free otherwise), it assumes a working queue, and it is a low-visibility single-vendor dependency. We de-risk that by keeping our integration thin and behind per-subscription flags, so we can replace it with a first-party dispatcher if support degrades. I'm asking for approval to run the spike, not to adopt.

To engineering: This is additive — Composer install, publish config and migrations, register the Nova tool, provision workers. No domain model intrusion beyond subscription and delivery-log tables. Three things I need you to pressure-test rather than assume: (a) v1.2.0 ships a transitive major bump (opscale-co/actions v4) in a minor release, so read the lockfile diff before you trust it; (b) delivery semantics — at-least-once vs. at-most-once, idempotency support, backoff and jitter — are undocumented in what we have; (c) operational guardrails: gate the Nova resource with policies, restrict outbound URLs against SSRF, and confirm delivery-log retention or we inherit unbounded growth. Keep business logic out of the package's extension points so this stays a replaceable boundary component, not a load-bearing one.