Laravel Webhooks Laravel Package

Technical Evaluation

Verdict for the PM: this is a sizing instrument and design reference, not a dependency to approve. It is archived, single-maintainer, has shipped nothing since May 2023, sits at 83 stars and zero dependents, and never reached a 1.0 (0.0.5 → 0.0.51 is the entire release history visible here). A TPM's job is to carry it as a timeboxed investigation line item with a written decision gate — "adopt a maintained alternative / build in-house / fork this" — and to actively prevent it from landing in composer.json by inertia because a spike "worked."

Architecture fit

• It is a thin, Laravel-idiomatic webhook implementation: service provider, publishable config, Eloquent models plus migrations for endpoints and delivery attempts, queued jobs, HMAC signing hooks, success/failure events. That shape maps directly onto a roadmap requirement like "notify tenant systems on order.created," which is why it is useful as a sizing instrument even if never installed.
• The coupling profile is the program-relevant detail. It is not a pure library: it owns database tables, a queue job type, a config namespace, and a signature header convention. Once any of those ship to external consumers, they become your versioned public contract. Signature format and retry semantics are effectively irreversible once a partner has built against them.
• Blast radius is genuinely small — a few hundred lines across a handful of classes. That is what makes the archived status a manageable risk rather than a fatal one: fork, replace, and discard all stay cheap. The TPM's role is to keep all three options open until the gate closes.
• Documentation contradiction to resolve on day one: the package blurb describes receiving and processing inbound webhooks, while the code shape described across prior assessments (endpoint registry, delivery attempts, queued signed POSTs) is clearly outbound. Do not let the team spend a spike on the wrong problem — confirm which direction the package actually implements before estimating anything against it.

Integration feasibility

• Mechanically trivial: composer require, publish config and migrations, dispatch from domain events. A spike is a day; a credible prototype a week. That is the full cost of the investigation, and it is why the spike is worth funding.
• The real gate is framework-version support. A May 2023 release implies illuminate/* constraints around Laravel 9–10 and PHP 8.1/8.2. On Laravel 11/12 the install likely fails or needs a constraint override — and overriding constraints on an archived package is the first step of an unplanned fork. Resolve this first; it is the cheapest possible kill criterion.
• Zero dependents means zero field validation. No production user base has surfaced the edge cases webhook delivery reliably produces: redirects, chunked responses, TLS quirks, non-2xx classification, slow endpoints, duplicate deliveries.

Technical risk

• Abandonment (high, already realized): no security patching, no PHP/Laravel major bumps, no CVE response path. Outbound delivery touches HTTP egress, secret storage, and SSRF surface — all security-relevant.
• Capability (high): "simple" almost certainly punts on what actually hurts — exponential backoff with jitter, per-destination rate limiting and circuit breaking, dead-letter and replay, idempotency keys, secret rotation with dual-signing, delivery observability, SSRF egress controls. Each must be verified in code, not assumed; verifying them is the spike.
• Contract (medium-high): header name, signature format, payload envelope, retry window, and delivery guarantee are customer-facing and expensive to reverse. This risk is independent of which library is chosen.
• Bus factor (high): one now-inactive maintainer, no escalation path, no vendor to escalate to.

Key questions to resolve before the gate

1. What illuminate/* and PHP constraints are declared, and does it install cleanly on our target matrix?
2. Does it persist delivery attempts with attempts/backoff/terminal-failed state — or fire once and log?
3. How are signing secrets generated, stored (encrypted at rest?), and rotated?
4. Is redelivery queue-retry only, or is there a replayable record a support engineer could act on?
5. Any egress restriction (private IPs, cloud metadata endpoints) or timeout configurability?
6. Do its migration table names and model names collide with our schema, and are they overridable without a fork?
7. What is the payload envelope, and is it versionable?

Integration Approach

Stack fit

• Clean if we are on Laravel 9/10 with PHP 8.1/8.2 and already operate a queue worker (Redis/SQS/database). It assumes Laravel's queue, HTTP client, and Eloquent — nothing new to operate.
• Poor fit on Laravel 11/12, or if the product needs multi-tenant endpoint isolation, per-tenant rate limits, or an outbound egress proxy. Those are exactly the layers an archived "simple" package never grew — and they are the layers that dominate the real estimate.

Options to put to the decision gate (effort and exit cost)

1. Spike this package (1–2 days, one engineer). Install against our real Laravel/PHP matrix, drive one end-to-end signed delivery, inspect the retry and failure paths. Output: a written capability matrix against the questions above. Near-zero cost; resolves version and capability unknowns with evidence.
2. Benchmark candidate: spatie/laravel-webhook-server. Actively maintained, the ecosystem default, similar queued-job-plus-signing model. Evaluate in the same spike against the same matrix so the gate is a like-for-like call rather than a gut feel.
3. Fallback: build in-house (~300–600 LOC) on Laravel's HTTP client and queue — endpoint model, delivery job with backoff and attempt ceiling, signer. Realistic at 2–3 weeks including hardening; removes the ownership problem entirely, and is likely where a partner-facing SLA lands anyway.
4. Reference-only use. Read it for naming, config ergonomics, and event-to-dispatch wiring. Zero exit cost — and the honest description of most of this package's value to us.

Compatibility considerations

• If any adoption path is taken: fork to an internal namespace, pin to a commit, and publish-and-own the migrations. Do not plan on upstream fixes; there will be none.
• Lock the customer-facing contract as a versioned spec before any code ships — header name, signature format, payload envelope, retry window, at-least-once semantics. Then a library swap becomes an implementation detail rather than a breaking change for partners. This is the single highest-leverage TPM action in the whole effort and it costs a document, not a sprint.
• Check config-key and migration table-name collisions against existing packages before the spike, not after.

Sequencing (milestones a TPM can track and report on)

1. Contract spec drafted + spike executed → decision gate (maintained alternative / in-house / fork this). No code beyond the spike until this closes.
2. Data model and migrations; secret encryption; endpoint registration with a verification handshake.
3. Dispatcher and queue job with backoff, timeout, and max-attempt termination.
4. Observability: per-delivery records, attempt logs, success/failure events, operator-visible replay.
5. Hardening: SSRF egress controls, secret rotation with dual-signing, load test at target volume.

Operational Impact

Maintenance

• Adopting this package means we own it forever from day one: dependency upgrades, Laravel major bumps, security review of the signing and outbound HTTP paths, and migration ownership. Do not model this as "one less thing to build" — model it as "one more thing to maintain," with no upstream to lean on.
• Reference-only use has essentially zero maintenance cost and captures most of the value. That asymmetry is the core of the recommendation.

Support

• There is no vendor, no support channel, no release cadence, and no CVE path. Any incident involving webhook delivery — failed partner notifications, a leaked signing secret, an egress misconfiguration — routes to our on-call, not to a maintainer.
• Zero dependents means no community knowledge base. Troubleshooting patterns are ours to invent. Budget for a named internal owner even in the spike phase.

Scaling

• The package's delivery model is per-endpoint, queue-driven, with no evidence of per-destination rate limiting or circuit breaking. In practice that means a single slow or hostile destination can consume workers and degrade delivery for everyone.
• Multi-tenant isolation, per-tenant quotas, and egress proxying are not features an archived "simple" package grew. If the roadmap includes partner-facing SLAs or regulated customers, assume those layers are a build, not a config flag.

Failure modes

• Silent loss: if retries are queue-only with no replayable record, a failed delivery is invisible to support and unrecoverable without engineering.
• Duplicate delivery: at-least-once is the realistic semantic; without idempotency keys documented in the public contract, partners will double-process.
• Framework break: a Laravel/PHP upgrade silently breaks an archived package with no upstream fix available; discovery usually happens during an unrelated upgrade sprint.
• Contract lock-in: a signature or envelope change after partners integrate becomes a coordinated migration, not a patch.
• Security exposure: outbound webhook dispatch is SSRF-adjacent; absent egress restrictions, endpoint URLs become a request-forgery primitive.

Ramp-up

• Low for any Laravel-fluent engineer — the codebase is small and idiomatic. The ramp-up cost is not reading the code; it is deciding who owns it and writing the contract spec first.
• Recommend a 1–2 day spike with a written decision gate and a named owner, reported as a timeboxed investigation line item. Ask for approval of the spike and the contract spec — not for a production dependency.