- How do I send an email using Resend in Laravel without changing my existing Mailables?
- Simply configure the `MAIL_MAILER=resend` in your `.env` and update `config/mail.php` to use the `resend` transport. Your existing Mailables will work out-of-the-box with Resend’s API, as the package integrates directly with Laravel’s mail system.
- Does this package support Laravel queues for async email delivery?
- Yes, the package fully supports Laravel’s queue system. When using `MAIL_MAILER=resend`, emails dispatched via `Mail::to()->send()` will be queued and processed asynchronously, just like with other Laravel mailers.
- Can I use Resend’s API directly (e.g., for bulk sends) without Laravel’s mail system?
- Absolutely. The package includes a `Resend` facade for direct API calls. Use `Resend::emails()->send()` to bypass Laravel’s mail system and send emails programmatically, which is ideal for non-Mailable use cases like notifications or bulk campaigns.
- What Laravel versions and PHP requirements does this package support?
- The package supports Laravel 11–13.x and PHP 8.1+. Older versions (e.g., Laravel 9.x or PHP 8.0) are explicitly deprecated. Always check the [README](https://github.com/resend/resend-laravel) for updates, as minor version bumps may extend support.
- How do I handle webhooks for email events like `email.failed` or `contact.created`?
- The package includes middleware (`VerifyWebhookSignature`) and event listeners for Resend webhooks. Configure routes in `routes/web.php` to handle incoming webhooks, then process events like `email.failed` or `contact.created` using Laravel’s event system or queue workers.
- Is there a fallback mailer if Resend’s API is down or throttled?
- No built-in fallback exists, but you can configure a secondary mailer (e.g., SMTP) in `config/mail.php` and use Laravel’s `fallback` option. Monitor API status and implement retry logic with Laravel’s queue system or a circuit breaker pattern for resilience.
- How do I test email delivery and webhooks in CI/CD without hitting Resend’s API?
- Mock Resend’s API using Laravel’s `Mail::fake()` for unit tests. For webhook testing, use a local HTTP server (e.g., Laravel’s `Http::fake()`) or a staging environment with a test API key. Avoid hitting production endpoints in CI.
- Can I use Resend’s idempotency keys or tags for deduplication?
- Yes, the package supports idempotency keys and tags. Pass them via the `Resend::emails()->send()` method or configure them in your Mailables using the `withResendOptions()` method. This is useful for preventing duplicate sends or segmenting emails by campaign.
- What are the alternatives to this package if I need multi-provider support?
- For multi-provider setups, consider abstracting the mailer layer (e.g., using a service container) or packages like `spatie/laravel-mail`. These allow switching between providers (e.g., Resend, Mailgun, SendGrid) without rewriting email logic. However, they add complexity compared to Resend’s native integration.
- How do I manage the `RESEND_API_KEY` securely across environments (dev/staging/prod)?
- Use Laravel’s `.env` files for local/dev environments. For staging/prod, leverage environment variables via your hosting provider (e.g., Heroku, AWS) or a secrets manager like HashiCorp Vault. Never hardcode keys in your repository.