- How do I install dniccum/nova-webhooks in a Laravel Nova application?
- Install it with Composer using composer require dniccum/nova-webhooks, then register the tool in your app's NovaServiceProvider. After that, run the package migrations to create the webhook endpoint and delivery tables. Publish any package config if the release provides it, then clear caches and confirm the tool appears in your Nova sidebar. Because this is an admin surface for event dispatch, plan the installation as a deployment with a migration step rather than a pure UI add-on.
- Does dniccum/nova-webhooks support Laravel Nova 5?
- Version 2.0.0 is described as a dependency-only change that adjusts constraints for Nova 5 compatibility. That strongly suggests the Nova 4 constraint was widened or dropped rather than dual-supported, so verify the composer.json constraint matrix before upgrading. Check which laravel/framework and nova versions your app is pinned to, since Nova upgrades often force a coupled Laravel minor bump. Do not assume Nova 4 and Nova 5 are supported by the same release.
- Which Eloquent model events can trigger a webhook in nova-webhooks?
- The package lets you attach webhooks to Eloquent model events such as created, updated, and deleted, configured through the Nova admin UI. Every event you expose effectively becomes part of your public API contract, so curate the list deliberately instead of blanket-exposing everything. Map the event names and payload shape before enabling endpoints in production, and document them for downstream consumers like Zapier or IFTTT.
- Do I need Laravel Nova to use dniccum/nova-webhooks?
- Yes. This package is a Nova tool that layers webhook management onto the Nova admin panel, so it offers nothing for teams using Filament, a custom Blade back office, or a headless API. It also does not own domain logic; it observes events dispatched by your application. If Nova is not your admin standard, use a general-purpose webhook package or a custom queued job instead.
- Is webhook delivery in nova-webhooks synchronous or queued?
- The release notes and changelog do not document delivery semantics, so treat this as unverified until you inspect the source or test it. Synchronous delivery inside the request cycle can slow responses and risk timeouts, while naive fire-and-forget can silently lose data. Before relying on it in production, run a full event dispatch against a real receiver such as a request-bin and confirm whether a queue worker is required. If queued delivery is not built in, plan to wrap or replace the dispatch path.
- Are nova-webhooks payloads HMAC-signed, and how do I rotate secrets?
- The changelog does not mention signing secrets, HMAC headers, or a rotation story, so confirm this in the code before exposing endpoints to third parties. Unsigned webhooks force consumers to trust the source by URL alone, which is usually unacceptable for production integrations. If signing is missing, consider adding a shared secret header at the HTTP client layer or using a package that signs payloads by default.
- Does nova-webhooks retry failed deliveries or handle timeouts?
- Retries, exponential backoff, per-endpoint timeouts, and dead-letter handling are not documented in the notes for the 1.1.3 or 2.0.0 releases. Webhook delivery is an at-least-once, failure-prone integration surface, so missing retry logic means your application inherits silent data loss when a receiver is down. Test failure scenarios in staging with an endpoint that returns 500 errors and observe whether the package records or retries the attempt. If it does not, add a queue-based retry layer around it.
- How do I upgrade from nova-webhooks 1.1.3 to 2.0.0 safely?
- Treat 2.0.0 as an infrastructure upgrade rather than a feature upgrade, since the release records only a dependency constraint change. Run composer show dniccum/nova-webhooks and composer why-not to see what pins you, then upgrade Nova 4 to Nova 5 first in a branch, followed by this package. Run the migration against a restored production snapshot to confirm it is idempotent and that existing endpoints, secrets, and delivery rows carry over. Finally, diff the payload shape against 1.1.3 output in staging, because silent payload changes are the classic major-version trap.
- Is there a delivery log, and can old webhook records be pruned?
- The package provides an admin UI for monitoring delivery activity, which implies stored delivery records for endpoints. What is not documented is retention, pruning, or replay of failed deliveries, and an unbounded delivery table is a real growth risk on busy models. Check the migrations for indexes and timestamps, then schedule your own pruning job or add a retention policy. Also confirm whether you can inspect and replay a failed payload, since that determines how recoverable delivery failures are.
- Is dniccum/nova-webhooks actively maintained, and what are the alternatives?
- It is a single-maintainer, community-authored package with an event-driven release cadence rather than a published roadmap, and the 2.0.0 changelog records a single pull request. Confirm whether an automated test suite exists and whether CI runs against multiple Nova and Laravel majors before committing. If you need stronger delivery guarantees, signing, and retries, look at dedicated webhook packages or a custom queued job using Laravel's HTTP client, especially on non-Nova or headless stacks.