Larahook Laravel Package

Product Decisions This Supports

• Build vs. buy for outbound integrations. Larahook is a hook layer for Laravel's Eloquent model events: instead of partners polling your API for changes, your app pushes signed HTTP payloads to subscriber URLs when records are created/updated/deleted. This lets you ship a "webhooks" integration surface as a product feature without building delivery, signing, and subscription storage from scratch.
• Public/integration API roadmap. Supports the decision to expose an event-driven integration API alongside (or instead of) a REST polling API. This is typically the cheaper path to partner integrations, Zapier-style automation, and customer-side sync jobs.
• Per-tenant or per-customer subscriptions. Because subscriptions are configured and stored in your own database, this supports product decisions about customer-configurable notifications ("notify my ERP when an invoice is paid") without standing up a separate integration service.
• Time-to-market for a first webhook feature. Reasonable for an MVP or a v1 integration surface where the alternative is a 1–2 quarter internal platform build.
• Upgrade planning (this release). 1.4.3 is a compatibility-only release adding Laravel 13 support. It does not add product capability, but it does mean this package is not a blocker if the roadmap includes moving the app to Laravel 13. Treat it as a maintenance-risk datapoint, not a feature.
• Decisions it should not drive. It is not a substitute for an event bus, a change-data-capture pipeline, or a delivery platform with per-endpoint SLAs, replay tooling, and subscriber-facing dashboards. Don't let adopting it defer a decision on those if you have enterprise integration commitments.

When to Consider This Package

Consider it when most of the following are true:

• You have a Laravel/PHP application where the events that matter to external systems are Eloquent model lifecycle events (orders, invoices, tickets, subscriptions).
• You need customer- or tenant-configured subscriptions stored in your own DB, with signed payloads so receivers can verify authenticity.
• Your volume is moderate and bursty rather than continuous-firehose — tens to low thousands of deliveries per minute at peak, not millions per hour.
• You want delivery handled asynchronously via your existing queue (Redis/SQS/database) rather than introducing a new infrastructure dependency.
• You are comfortable owning the operational surface: retry policy, dead-letter handling, failure visibility, and endpoint management UI are yours to build or configure.
• You value staying on the Laravel upgrade treadmill — 1.4.3 confirms Laravel 13 compatibility, so adoption doesn't create a future upgrade blocker.

Look elsewhere when any of the following apply:

• You need delivery guarantees with formal SLAs, exactly-once semantics, automatic replay of failed deliveries from a retained log, or subscriber-facing delivery dashboards — evaluate managed providers (e.g. Svix, Hookdeck) or build an outbox pattern with a durable log.
• Your events are not Eloquent-driven — domain events, third-party callbacks, scheduled jobs, or cross-service events won't map cleanly to model lifecycle hooks.
• You need payload schema versioning and contract governance across many partners; that logic sits above this package and must be designed deliberately.
• You need high fan-out or high throughput delivery where per-event queued jobs become a cost or latency problem.
• Package maintenance depth matters more than convenience. This is a single-maintainer-origin, small-footprint package; 1.4.3 is a minor compatibility bump and demonstrates responsiveness, but assess bus-factor and release cadence against your support expectations before making it load-bearing.

How to Pitch It (Stakeholders)

For executives (30 seconds). We can ship a customer-facing webhook/integration capability in weeks instead of quarters by building on Larahook, an open-source Laravel package. It turns changes in our data into signed notifications pushed to customer endpoints — the mechanism behind "notify my system when X happens." The latest release (1.4.3) is a maintenance update that adds Laravel 13 support, which means adopting it now doesn't complicate our framework upgrade path. The trade-off is that it gives us the plumbing, not the product: retries, monitoring, failed-delivery replay, and the self-serve subscription UI remain our responsibility. Recommendation: adopt for a first integration surface, and revisit a managed delivery vendor once we have paying customers depending on delivery reliability.

For engineering. 1.4.3 is a compatibility-only change (Laravel 13 support); no API changes, no deprecations, no migration work implied. The package hooks Eloquent model events and dispatches signed HTTP calls through our queue, with subscriptions persisted in our database. Adopting it means we own the queue configuration, retry/backoff policy, failure logging and alerting, payload contract/versioning, and endpoint self-service. Plan for an internal abstraction in front of it so that subscription storage and delivery can be swapped for an outbox or a managed provider without rewriting call sites. Before committing, confirm maintenance cadence and bus factor, and add an integration test asserting payload shape and signature verification so an upstream minor release can't silently change our contract.

Bottom line. Low-risk, high-leverage for a first webhook feature; not a platform for guaranteed delivery at scale. The 1.4.3 release is a positive maintenance signal, not a reason on its own to adopt.