Mailjet Bundle Laravel Package

Product Decisions This Supports

• Transactional email reliability as a product surface. Password resets, receipts, onboarding sequences, and notification digests all run through this layer. The build/buy question underneath the package is whether we own deliverability, templating, suppression lists, and bounce handling — or rent them from Mailjet. That decision maps to activation, retention, and support-ticket volume, not to "plumbing."

• Framework-fit as a roadmap input, not a footnote. Despite the Laravel framing in the description, the -bundle naming, DI-extension conventions, and self-hosted forge location all point to a Symfony bundle that may not auto-discover in Laravel at all. Before this touches an architecture diagram, the PM decision is "confirm the shape" — because a wrong-framework dependency is a schedule risk, not a code-style preference.

• Feature scope for the messaging layer. A thin Send-API wrapper constrains what product can promise marketing and growth: 1:1 transactional mail only, with no Mailjet-hosted template versioning, no campaign/broadcast sends, no contact-list sync. If the lifecycle roadmap includes an email preference center or per-tenant sending domains, that work is ours to build regardless of this package.

• Deliverability and compliance sequencing. Bounce/complaint webhooks, unsubscribe handling, and audit trails are product-visible (CAN-SPAM/GDPR, sender reputation). Whether the integration surfaces these events determines whether "email preference center" is a Q1 or Q3 commitment.

• Vendor-swap optionality as a budget line. The abstraction we choose now sets the cost of migrating to SES, Postmark, or Resend later. A thin, unmaintained wrapper raises that cost; a mailer-based or interface-based path keeps it low.

• A recorded non-decision. With 0 stars, 0 dependents, and a 0 score, the defensible PM call is "no decision — spike only, reference only." Writing that down stops the team from re-litigating it every quarter.

When to Consider This Package

Consider it when:

• The stack is genuinely Symfony, and the goal is wiring Mailjet credentials as an injected service rather than hand-rolled cURL in a controller.
• Scope is narrow and reversible — one or two transactional send paths, an internal tool, or a spike where a failed send is annoying rather than revenue-impacting.
• You need a reference implementation to read before writing your own ~60-line client. This is its highest-value use today.
• Someone owns it: vendored, commit-pinned, and patched in-repo rather than trusted as an upstream release.

Look elsewhere when:

• The stack is Laravel — use the framework's built-in Mailjet transport (MAIL_MAILER=mailjet plus a DSN) or the official mailjet-apiv3 SDK bound in a service provider. Zero new dependency either way.
• You're on modern Symfony — symfony/mailjet-mailer is first-party and maintained, and wins on maintenance grounds almost every time.
• Email is revenue-critical: no stars, no dependents, no visible test suite or CI means no signal on security response time, API-version churn, or PHP minor-version breaks.
• You need webhook ingestion, suppression management, template versioning, batch send, or per-tenant credential routing — a thin wrapper won't provide it and you'll build it anyway.
• Procurement or security review requires a named owner, changelog, license, and disclosure policy. The package lives on a self-hosted forge (support.appi.works), which means Composer needs an explicit vcs entry plus credentials in every dev environment and CI runner — a build-fragility cost the framework-native path doesn't carry.

How to Pitch It (Stakeholders)

To executives: Mailjet is a commodity email provider; the integration layer is a small, cheap decision with one real risk — supply chain. This specific package shows zero adoption: no stars, no dependents, no release cadence, no visible license or test suite, and it's hosted on a single-maintainer forge rather than Packagist. We should not treat it as a supported dependency for anything customer-facing. The recommendation is to standardize on the maintained, framework-native Mailjet path — roughly a day of engineering — and use this package only as reading material. Cost is negligible either way; the difference is who we call when password resets silently stop delivering.

To engineering: Treat royalpunk/mailjet-bundle as a thin DI wrapper around the Mailjet API, not an email platform. It plausibly gives configuration-driven credentials and an injectable client; it does not give retries, idempotency, webhook handling, or observability. Prefer Laravel's built-in Mailjet transport, or the official SDK behind our own small MailTransporter interface so providers are swappable without touching call sites. If we adopt it, fork it into app/Support/, pin a commit SHA, and add the tests it's missing. All sends queue via ShouldQueue with explicit retry/backoff, and errors must distinguish retryable (429/5xx) from terminal (400/422) — silent non-delivery is the failure mode we cannot accept on receipts or resets.

Ask: approve a one-day spike to confirm framework fit and wire the framework-native path; do not add this package to the dependency manifest without a named owner and a fork plan.