Webhooks Api Laravel Package

Product Decisions This Supports

• Build vs. buy for webhook subscription management. This package addresses the presentation/API surface of webhooks — the endpoints, controllers, request validation, and response shaping for letting users register and manage webhook subscriptions. That distinction is the decision it informs: it can cover the CRUD/config half of a webhooks epic, but it does not cover delivery, retries, signing, or observability. Scope the epic accordingly rather than treating this as a turnkey webhooks feature.
• Roadmap sequencing for a partner/integration ecosystem. If the roadmap includes “let customers subscribe to events” (order.created, invoice.paid, etc.), this package shortens the time to a usable configuration API, which is usually the gating item before partner onboarding can begin.
• Architecture: modular monolith with isolated presentation adapters. Adopting it is implicitly a vote for keeping HTTP concerns separate from webhook domain logic. That is a reasonable bet — it keeps the domain swappable — but it should be a conscious architectural decision, not a side effect of dependency selection.
• Use cases it plausibly supports: self-service webhook configuration in an admin or developer dashboard, tenant-level event subscriptions, an internal control plane for service-to-service eventing, and a thin API layer in front of an existing webhooks domain module.
• Effort sizing and risk budgeting. Because the package is presentation-only, the PM-relevant estimate becomes “X days for the config API (partly covered) + Y weeks for delivery, retries, and signing (not covered).” That split is the number to take to planning.

When to Consider This Package

Consider it when:

• You are already committed to the Liberusoftware module layout and the underlying webhooks domain/application layers exist or are planned. The adapter is only valuable as a layer on top of something.
• You need only the HTTP/presentation layer — routes, controllers, form requests, API resources — and intend to own delivery infrastructure separately.
• You are willing to treat it as vendored source rather than a trusted dependency. Zero stars, zero dependents, a single vendor, and a release date that reads as future-dated all point to “fork it, pin it, and own it,” not “composer require and forget.”
• The first exposure is internal or low-blast-radius — an admin surface or a beta cohort — not a public, SLA-bound developer API.

Look elsewhere when:

• You need managed delivery guarantees — retries, exponential backoff, HMAC signing, dead-letter queues, delivery logs, replay. Buy (Svix, Hookdeck) or use a mature in-app option such as spatie/laravel-webhook-server; this package is not that.
• You are not on this module stack. The adapter then delivers coupling cost with no offsetting benefit.
• You need a public developer-facing webhooks API at launch. Zero adoption means zero community-vetted edge cases, and you would be the first to find them.
• No one on the team can own a fork. With no dependents and no stars, upstream support is effectively you.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost accelerator for the configuration half of our webhooks capability — the part where customers register endpoints and pick events. It gets partner onboarding moving sooner and costs nothing to license. The honest framing is that it is an unproven, single-vendor package with no adoption; we should position it as scaffolding for an internal-first surface, not as the backbone of a public integration platform. The delivery engine — retries, signing, monitoring — is still our build (or a buy), and that is where the real cost and risk sit. Recommendation: approve a time-boxed spike, not a platform commitment.

To engineering: Treat it as a thin presentation adapter, not a framework. Vendor or fork it, pin to a commit, and wrap it behind our own interface and contract tests so the domain stays ours and the swap cost stays low. Validate that the domain and application layers it expects actually exist in our codebase before we plan around it. Budget explicit ownership: someone has to read this code, because nobody else has.