Laravel Webhook Client Laravel Package

Product Decisions This Supports

• Build vs. buy for inbound webhook ingestion. Every partner integration (Stripe, GitHub, Shopify, Twilio, Segment, internal services) otherwise gets its own bespoke controller, HMAC check, raw-payload log, and retry handling. This package collapses that into one config-driven pipeline with five named extension points — signature validator, webhook profile, storage model, processing job, HTTP response — so the recurring pattern is bought/inherited once and only the provider-specific parts are written.
• Integration roadmap sequencing and sizing. Once inbound webhooks are a standardized path, the marginal cost of "add provider N" drops from a multi-day build to roughly "write a signature validator + a job." That directly changes how many integrations you can commit to in a quarter and lets you price partner-driven roadmap items honestly.
• Security posture as a default, not a per-project decision. Signature verification runs before anything is persisted, and invalid signatures are discarded and surfaced via InvalidWebhookSignatureEvent. That means "did we verify the payload?" stops being a code-review question and becomes an architectural property you can assert to security and in a SOC 2 / vendor-review questionnaire.
• Auditability and incident response. Raw payloads land in webhook_calls (headers too, or * for all), and queue-dispatch exceptions are captured on the record. That gives support and on-call a queryable source of truth for "the provider says they sent it, we say we never got it," and a concrete replay path — re-dispatch the job from the stored model rather than asking the partner to resend.
• Reliability and SLA design. Storing first and queueing second means you respond fast (default 200) and do real work asynchronously. That is the difference between meeting a partner's 5-second acknowledgement window and failing it under load — and it's the design decision that makes an ingestion SLA defensible.
• Data retention and compliance scoping. delete_after_days (default 30) makes retention an explicit, reviewable setting rather than an accident of never deleting rows. Webhook payloads frequently contain PII, so this is a lever you can point at legal/DPO review.
• Filtering decisions stay product-owned. WebhookProfile lets you decline event types you don't care about before they're stored — so noise reduction, cost control, and "we only process what's on the roadmap" become a small class rather than a data-cleanup backlog item.
• Multi-provider and multi-tenant surface in one deploy. Multiple named configs allow several receiving endpoints, each with its own secret and validator, so per-partner isolation doesn't require per-partner services.

When to Consider This Package

Consider it when most of the following hold:

• The product is a Laravel/PHP application and inbound webhooks are an existing or near-term requirement.
• You expect two or more webhook providers — the payoff is in the second and third integration, not the first.
• You want an audit trail and replay capability without building an admin surface for it; the webhook_calls table is a usable v1.
• The team is small or has limited platform bandwidth, and "one more webhook endpoint" keeps landing on the same two engineers.
• Queue infrastructure already exists (Redis/SQS/database queue). The README explicitly warns against the sync driver, so a synchronous-only deployment is a real adoption blocker.
• Your providers use HMAC-SHA256 over the raw body (the default), or you're willing to write a ~20-line SignatureValidator per provider that doesn't. Budget that as per-integration work, not zero — Stripe's timestamped t=,v1= scheme, Shopify's base64 variant, and prefixed headers all need custom validators.

Look elsewhere, or build around it, when:

• You're not on Laravel — the value is almost entirely in the framework integration (routing macro, service provider, Eloquent model, queue job base class). Little transfers.
• Ingest volume is the bottleneck. This is an application-tier receiver; if you're absorbing high-throughput event streams, you want an edge/gateway layer (a dedicated webhook relay or queue-first ingestion service) in front, with this package behind it — or not at all.
• You need managed idempotency, automatic retry reconciliation, secret rotation workflows, and a non-engineer replay/debug console out of the box. None of those ship here; you'd be building them on top (profile-based dedup is possible but you own it).
• You also need to send webhooks — that's the sibling laravel-webhook-server package, and worth evaluating as a pair so outbound and inbound don't diverge stylistically.
• Dependency policy is restrictive. Dependents count is 0 and the overall health score is modest; a conservative org may prefer to vendor or reimplement the ~small core rather than add a dependency. Mitigating factor: MIT license, small surface area, changelog and dated releases, and a well-known maintainer — so fork risk is low even in the worst case.

How to Pitch It (Stakeholders)

For executives: Inbound webhooks are the connective tissue of our partner integrations, and today each one is hand-built — verification, logging, retry handling, and error capture reimplemented slightly differently every time. This package makes that a solved, standardized path. The business consequence is that integration work shifts from "build an ingestion pipeline" to "implement one provider's rules," which is where the actual differentiation is. It also gives us, by default, two things we currently lack: proof that every payload was cryptographically verified, and a durable record of every payload received that support and on-call can act on. It's MIT-licensed with a mature, actively released codebase, so there's no vendor commitment and no lock-in — the exit cost is low because the core is small and the extension points are ours.

For engineering: This replaces the ad-hoc webhook controller with a five-stage pipeline you configure, not fork: verify signature → apply a profile filter → persist to webhook_calls → dispatch a queued job → return a response. Each stage is an interface (SignatureValidator, WebhookProfile, RespondsToWebhook) plus a swappable Eloquent model and job base class, so provider-specific logic lives in our code and framework concerns stay in the package. Signature failures never touch the database and emit an event we can alert on; queue-dispatch exceptions are persisted on the record instead of vanishing. Register the route with Route::webhooks(...) and exclude it from CSRF. The one hard prerequisite is a real queue driver — do not ship this on sync, since the whole design premise is acknowledging fast and processing later. Two caveats to plan for rather than discover: provider signature schemes that aren't plain HMAC-SHA256-over-body need a custom validator, and deduplication/idempotency is not built in — if a provider can deliver the same event twice, we own that in the profile or the job. Treat webhook_calls as PII-bearing and confirm the retention window with legal before launch.