- Is wildbit/postmark-php a Laravel package or a framework-agnostic SDK?
- It is a framework-agnostic PHP SDK for the Postmark API, not a Laravel package. It ships no service provider, config publish, facade, or Laravel-native testing fakes. You can use it in any PHP application, including Laravel, but all Laravel ergonomics such as container bindings, config shape, and exception mapping are yours to build.
- How do I install wildbit/postmark-php in a Laravel app?
- Install it with composer require wildbit/postmark-php and then create a thin service provider that binds a configured client instance into the container. Keep your API token in config and environment variables rather than hard-coding it. The install itself is quick; the real work is the seams such as exception mapping and testability.
- Should I use this SDK instead of Laravel's built-in Postmark mail transport?
- For routine outbound transactional mail, no. Laravel's Mail facade already sends through Postmark via Symfony Mailer's Postmark API transport, and switching away loses queue integration, Markdown mailables, mail fakes, and Mail::assertSent coverage. Adopt the SDK only for capabilities the framework transport does not expose, such as inbound webhook parsing, template and stream administration, and bounce or suppression queries.
- Does wildbit/postmark-php support batch sending and templates?
- Yes. The SDK supports single and batch sends, templates, attachments, message streams, and template management. These are exactly the areas where it adds value beyond Laravel's default mail transport. Batch sending and template administration are good candidates to wrap behind your own interfaces.
- Which PHP and Laravel versions does wildbit/postmark-php support?
- The SDK is a clean fit for Laravel 10, 11, and 12 on PHP 8.1 and above, used as a supplementary client. You should still confirm the SDK's PHP version floor matches your application's matrix before committing. Since it is framework-agnostic, Laravel version support depends on your own integration code rather than the package.
- How do I handle Postmark inbound webhooks in Laravel with this SDK?
- Use the SDK to hydrate inbound message payloads and to verify webhook signatures, then hand the result to your own controller or job. Wrap the parsing behind a narrow interface such as an InboundParser so vendor-specific payload shapes do not leak into your domain. This keeps a future provider swap to roughly a week of work instead of a rewrite.
- Can I test a Postmark integration without hitting the live API?
- The SDK does not provide Laravel-style fakes, and the evaluation notes question whether it ships reusable recorded-response fixtures, so plan for your own test doubles. Put the client behind an interface and inject a fake or a mocked HTTP client in tests. That also solves the broader problem of making the client testable offline.
- Does wildbit/postmark-php support PSR-18 injection or does it bundle Guzzle?
- The SDK has historically bundled its own Guzzle-based HTTP client rather than accepting PSR-18 injection, which risks two Guzzle majors in one dependency tree. Confirm PSR-18 and PSR-17 support before committing. If absent, you accept a second HTTP client with its own timeout, retry, and proxy semantics.
- How do I manage bounces, suppressions, and message streams with the SDK?
- The SDK exposes bounce, suppression, stream, sender signature, domain, server, and message-events APIs that Laravel's mail transport does not surface. Use it behind your own interfaces for deliverability telemetry and stream or template administration. Keep these calls confined so Postmark-specific payloads do not spread through your domain code.
- Is wildbit/postmark-php well maintained, and what about vendor lock-in?
- It is the official Postmark library maintained by Wildbit with a recent release in July 2025 and an MIT license, so the low star count is a poor signal for a narrow official SDK. Bus factor is limited since external contributions are few, so be prepared to pin and maintain a small fork if it stalls. To limit lock-in, wrap the SDK behind your own interfaces, because switching to a competing SDK is a rewrite rather than a config change.