- What is pushery/webhooks-for-laravel used for?
- It is an all-in-one, config-gated webhooks toolkit for Laravel applications. It sends signed outbound webhooks, receives and verifies inbound webhooks, provides a customer self-service endpoint portal, and adds an observability dashboard over delivery logs. You can enable only the layers you need, and Standard Webhooks signatures are the default.
- How do I install and configure pushery/webhooks-for-laravel in Laravel?
- Install it with Composer using composer require pushery/webhooks-for-laravel, then publish and adjust the package configuration for the layers you want to enable. Storage runs on PostgreSQL or MySQL 8.4+, or on no database at all if you only send webhooks. The package uses the Pushery\Webhooks namespace and Laravel-native conventions such as PendingWebhook::create()->dispatch().
- Does pushery/webhooks-for-laravel support Standard Webhooks signatures and Ed25519?
- Yes, Standard Webhooks signatures are used by default so deliveries are verifiable by any Standard Webhooks consumer. Ed25519 signing is optional for teams that want modern cryptographic signing. Ed25519 requires PHP's sodium extension, so HMAC remains the practical fallback when sodium is unavailable.
- Which Laravel and PHP versions does webhooks-for-laravel support?
- Check the Packagist package page and README badges for the current PHP and Laravel version constraints before installing. The package is built around Laravel-native features such as Route::webhook(), Webhook::send(), Webhook::listen(), queues, and jobs. Confirm the exact supported matrix against your application's Laravel and PHP versions.
- Why does pushery/webhooks-for-laravel refuse database table prefixes?
- As of v3.14.0 the package refuses a connection configured with a table prefix before any migration runs, naming the prefix and the way out. This is a deliberate constraint that prevents a mid-migration failure and makes host-schema expectations predictable. Hosts standardised on prefixes must use a dedicated unprefixed connection or a prefix-free schema.
- How does the SSRF guard handle IPv6 addresses in webhooks-for-laravel?
- The v3.14.0 SSRF guard refuses all non-globally-reachable IPv6 space, including 5f00::/16, 100:0:0:1::/64, the 2001::/23 IETF protocol-assignments block, and any IPv6 outside the global unicast block 2000::/3. Embedded IPv4 literals are still judged as IPv4. This materially strengthens outbound webhook safety for production use.
- How do queued retries and rate limits behave on SQS FIFO queues?
- On SQS FIFO queues a deferred delivery is not deferred onto the queue because FIFO takes no per-message delay. The Retry-After hint is clamped to the configured cap and counted as an ordinary retry, which FIFO does honour. Rate-limited deliveries on the sync connection or a FIFO queue no longer wait for their slot, but WebhookDeliveryRateLimited still fires with the delay. Confirm this behaviour against any rate-limit SLA you promise customers.
- Can customers manage their own webhook endpoints with this Laravel package?
- Yes, the package includes a config-gated self-service portal so customers can manage their own webhook endpoints. This aligns with SaaS multi-tenancy patterns through a Laravel resource such as WebhookEndpoint. You can combine it with the delivery dashboard to observe endpoint health and delivery history.
- What are the production concerns for sending webhooks with pushery/webhooks-for-laravel?
- Plan for Ed25519 sodium availability, the hard refusal of prefixed database connections, and dashboard dependencies such as Blade or Livewire if you use real-time updates. Outbound webhooks do not include built-in idempotency keys, so implement retry safety with Laravel queues and unique job constraints where needed. Inbound schema validation depends on manually defined schemas, so complex payload contracts may need additional tooling.
- How do I test inbound webhook verification and outbound deliveries?
- Test outbound deliveries by faking the queue, asserting the PendingWebhook URL and payload, and verifying the signature with a Standard Webhooks consumer. For inbound routes, send signed requests and assert that verification passes or fails using a test secret. The package itself is tested with Pest on PostgreSQL and MySQL, but your application should still cover endpoint-specific contracts and retry behaviour.