- Is azine/mailgunwebhooks-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, registered in the Symfony kernel and configured through bundle configuration with routing imported from YAML files. It ships no Laravel service provider, facade, config publishing, Eloquent models, or Artisan commands. Reusing it in a Laravel application means writing an adapter or forking the package.
- Can I use azine/mailgunwebhooks-bundle in a Laravel application?
- Only indirectly. Laravel's illuminate components usually co-resolve because Laravel no longer requires doctrine/dbal, so class conflicts are unlikely, but there is no first-party Laravel integration to lean on. The realistic paths are wrapping or forking it inside Laravel, pinning to the older 4.x line, or running it as a standalone Symfony 7.4 webhook receiver that feeds Laravel through a queue or shared storage. In practice the PHP 8.5 runtime floor, not Composer resolution, is the install blocker.
- What PHP version does version 5.0.0 require?
- Version 5.0.0 requires PHP 8.5, which is well ahead of what most production Laravel estates, managed hosts, and serverless runtimes certify. That makes it a platform-lifecycle constraint rather than a simple Composer constraint. If your infrastructure cannot run PHP 8.5, the 5.x line is effectively unavailable and you should stay on 4.x.
- What changed in 5.0.0 compared to 4.x?
- 5.0.0 is a major breaking release: it modernizes to Symfony 7.4 dependency injection with attribute-based wiring, Doctrine ORM 3, Twig 3, and Symfony Mailer instead of SwiftMailer, and it raises the runtime floor to PHP 8.5. Functionally it adds strict webhook signature validation, replay and deduplication handling, safe error responses, and bounded notification retries. That is a significant gain in security and data integrity, but a significant loss in the environments it can run in.
- How do I install and register azine/mailgunwebhooks-bundle?
- Add azine/mailgunwebhooks-bundle to your Composer requirements, then register AzineMailgunWebhooksBundle in your kernel and import the bundle's webhook and admin routing files. There is no Laravel install path: nothing publishes configuration and there is no service provider to register. In Laravel you would have to wire the container bindings, routes, and scheduling yourself as part of an adapter or fork.
- Does the bundle support Doctrine ORM 3, or can I swap in Eloquent instead?
- 5.0.0 requires Doctrine ORM 3, which removed the annotation driver and several legacy APIs and pulls in stricter DBAL 4 dependencies. Swapping Doctrine for Eloquent is harder than it was against ORM 2: you must port against ORM 3 semantics or accept running two persistence layers in the same application. The bundle is not designed around Eloquent models, so a clean Eloquent fork is a substantial rewrite.
- What Mailgun webhook data does the bundle capture and store?
- It captures everything Mailgun posts to the configured webhook URL, covering delivery, bounce, spam-related bounce, and other event types, and stores it so you can search, filter, display, and delete entries. This matters most on free Mailgun accounts, where log entries are deleted after roughly 48 hours. Each stored event has a detail view, and those records back the admin list screens.
- What CLI commands does the bundle provide for maintenance?
- It provides a command to delete old events and reclaim disk space, and a command that checks Mailgun's sending IPs against blocklists and emails the administrator when an IP appears on a blacklist. It also emails the administrator when mails bounce because of a spam rating. These are Symfony console commands, so a Laravel port would need them rewritten as Artisan commands and scheduled through the Laravel scheduler.
- Can I use the bundle's Twig admin UI in a Laravel app?
- Not without conversion. The admin screens are Twig 3 templates and there is no Blade variant, so any in-scope admin surface means a templating port. If you only need webhook capture, verification, and storage, you can skip the UI entirely and render the data with your own Laravel views.
- What are the alternatives for handling Mailgun webhooks in Laravel?
- There are three practical routes: build an adapter or fork inside the Laravel app, pin to the prior 4.x line to avoid the PHP 8.5 floor, or deploy the bundle as an isolated Symfony 7.4 webhook receiver on PHP 8.5 and feed Laravel through a queue or shared storage. Note that Laravel already gives you much of what 5.0.0 adds, including queued jobs, notifications, signature verification middleware, and idempotency, so a fork should keep only the Mailgun-specific parsing and storage logic.