Product Decisions This Supports
- Whether inbound webhook ingestion is a product surface at all. This package exists to receive and process third-party webhooks: route registration, payload/header persistence, queued processing, signature-verification hooks. That is a different decision than "should we emit webhooks to customers," and it is the one this repo actually informs. Frame the question as: do we have (or expect) enough provider integrations that hand-rolled controllers per provider become a maintenance tax?
- Build vs. buy on integration plumbing. The realistic outcome here is not "add a dependency" — it is "read a few hundred lines of Laravel-native code and price the first-party build with evidence." That converts a blank-page estimate into a defensible range (roughly 1–2 weeks for a simple inbound handler; materially more once replay, retention, and PII handling land).
- PRD scope and explicit non-goals. It makes the expensive parts visible before commitment: signature verification per provider (each with its own scheme), idempotency/dedupe on provider event IDs, replay of stored payloads, retention windows on payloads that contain customer PII, failure alerting, and backpressure when a provider bursts. Write the non-goals down ("no replay in v1," "no per-provider replay UI") rather than discovering them in an escalation.
- Risk and compliance posture for stored payloads. The package's core value — persisting raw payloads and headers for auditing and debugging — is also its core liability. That triggers a data-retention decision (how long, encrypted at rest, who can read, does it land in our DPA/SOC 2 scope) that a PM should own at design time, not after the first security review.
- Spike and prototype decisions. For an internal tool, a partner demo, or a "we need to accept Stripe/GitHub/Shopify events by Friday" situation, it is cheap enough to validate the UX in days. Treat it as a timeboxed spike with an explicit decision gate — adopt a maintained alternative / build in-house / fork — not as an approved line item.
- Reference architecture for an in-house build. MIT-licensed and small, so the honest product decision is "reuse the design and naming, own the code." That preserves all three exit options (fork, replace, discard) while you learn.
Due-diligence flag for the PM: the package description covers inbound receiving and processing, while prior internal notes on this repo discussed outbound delivery (subscriptions, HMAC-signed POSTs, retry policy). Those are different products with different buyers, different risk profiles, and different alternatives. Resolve which problem you are actually solving on day one — sizing an outbound platform off an inbound reference (or vice versa) is the single most likely way to get this estimate wrong.
When to Consider This Package
Consider it when:
- You need to receive webhooks from a handful of third-party providers in a Laravel app and want a readable, working model of route registration, payload persistence, and queued processing before you commit to a design.
- The team is small and Laravel-fluent, and the alternative is a from-scratch design with no prior art to argue against.
- Volume is low and the surface is internal or partner-facing-but-tolerant, where a dropped or duplicated event is an inconvenience rather than a contractual breach.
- You are willing to vendor or fork it, pin to a commit, name an owner, and accept that you — not upstream — will review signature verification and the persistence path.
- The deliverable is a spike, a demo, or a written spec. Cost of investigation is genuinely near zero.
Look elsewhere — or budget a fork with a named owner — when:
- It would become a production dependency. It is archived, last released May 2023, has 83 stars and zero dependents. No security patching, no Laravel major-version guarantee, no escalation path, single inactive maintainer. "We'd be the only production user" is the deciding fact.
- You run Laravel 11/12 or modern PHP. A 2023 release implies Laravel 9–10 / PHP 8.1–8.2 constraints; overriding constraints on an archived package is the unplanned fork. Test this on day one — it's the cheapest kill criterion you have.
- You need the things "simple" typically punts on: per-provider signature schemes, idempotent dedupe, replay, retention/PII controls, dead-letter handling, per-source rate limiting, or observability dashboards. Assume you build all of them.
- You are in a regulated or audited context requiring SBOM provenance, vendor support, or a maintained release cadence.
- You need outbound webhooks (notify customer systems on
order.created). Different problem: benchmark spatie/laravel-webhook-server as the maintained default, or build in-house (~300–600 LOC, realistically 2–3 weeks with hardening).
PM recommendation: do not adopt as a runtime dependency in either direction. Fund a 1–2 day spike against your real Laravel/PHP matrix, pair it with a maintained alternative evaluated on the same capability matrix, and close with a written decision gate.
How to Pitch It (Stakeholders)
For executives: This is a small, MIT-licensed Laravel package that demonstrates how to accept and process webhooks from third-party services — the plumbing behind "when Stripe/GitHub/our partner fires an event, our product reacts." It is not a strategic dependency: the project is archived, has a negligible adoption footprint (83 stars, zero dependents), and has shipped nothing since May 2023. There is no vendor, no support channel, and no security patching, and the payloads it stores are exactly the kind of customer data our security review cares about. The recommendation is therefore not "adopt" but "use as a design reference and a sizing instrument." The value is de-risking the roadmap: it lets us scope the integration capability in days of investigation instead of weeks of blank-page design, and it surfaces the genuinely expensive parts — signature verification, dedupe, replay, retention and PII handling, failure visibility — before we commit to a date. Cost to evaluate is near zero; cost to depend on it in production is unbounded maintenance ownership. Ask: approve a short spike plus a written integration contract, not a dependency.
For engineering: Laravel-native and readable — service provider, publishable config and models, routes for webhook endpoints, persisted payloads and headers, queued jobs for processing, and verification hooks for trusted senders. It maps cleanly onto our existing queue and Eloquent conventions and is small enough that forking is cheap. The trade-off is explicit: the repo is archived, so we inherit the code, the Laravel-major compatibility risk, and the obligation to review signature verification and the payload-persistence path ourselves. Two asks. First, confirm on day one whether this installs cleanly on our target PHP/Laravel matrix — if it doesn't, the conversation ends there. Second, whichever path we take, publish-and-own the migrations and lock the customer-facing contract (endpoint shape, signature/verification scheme, payload envelope, dedupe key, retention window) as a versioned spec before shipping, so the backing library stays an implementation detail rather than a breaking change for partners. That document costs a day and is the highest-leverage artefact in the whole effort.