Mailjet Apiv3 Php Laravel Package

Product Decisions This Supports

• ESP / channel strategy. Anchors a decision to route transactional and marketing email through Mailjet's HTTP API rather than raw SMTP. The SDK exposes Send API v3.1 (['version' => 'v3.1']), the v3 Email API for contacts/lists/templates/stats, and the v4 SMS API from a single client — so "one vendor for email + SMS" becomes a testable option rather than a slide.
• Transactional messaging roadmap. Password resets, receipts, order confirmations, onboarding sequences, and alerts can all be scoped against a concrete, documented payload shape (Messages[].From/To/Subject/TextPart/HTMLPart). This makes "add email notifications" estimable in days, not quarters, and gives engineering a reference implementation to build against.
• Build vs. buy on the integration layer. The package is a thin, MIT-licensed transport wrapper — it does not contain your domain logic, templating strategy, retry policy, or suppression rules. That means buying the plumbing is cheap and low-commitment; the differentiated work (queueing, idempotency, preference centers, unsubscribe flow) remains in-house where it belongs.
• Marketing/CRM feature scoping. Resources::$Contact, $ContactManagecontactslists (with addforce / addnoforce semantics), $ContactData, $Template, and $Message unlock concrete backlog items: contact sync from signup, list segmentation, template CRUD without a CMS, and a delivery/engagement reporting dashboard via GET with Limit/Offset/Sort/showSubject filters.
• Compliance and deliverability decisions. The IsExcludedFromCampaigns filter and list-action API make suppression, unsubscribe, and exclusion-list behavior a first-class product requirement — relevant to GDPR/CAN-SPAM posture and to whether you need a separate preference-center build.
• Vendor-lock-in posture. Because the wrapper is thin and standards-based (PSR-18 client, PSR-17 factories), the switching cost to SES/Postmark/SendGrid is bounded to one adapter class. This supports a "commit to Mailjet for 12 months, keep the exit door open" position.
• Test/CI and environment strategy. The $CALL = false constructor flag lets QA and CI run end-to-end flows without hitting the live API — a small but real enabler for staging parity and for demo environments.
• Infrastructure standardization. Injecting your existing Guzzle or Symfony client (timeouts, proxies, force_ip_resolve => 'v4') means outbound email inherits the same observability, retry, and egress controls as the rest of the platform instead of becoming a snowflake.

When to Consider This Package

Adopt when:

• Mailjet is already the chosen or shortlisted ESP, or is being evaluated against a PHP/Laravel stack.
• The project is PHP 8.1+ and Composer-managed (Laravel 10/11 and Symfony both qualify).
• You need API-level access beyond "send an email" — contact list management, template CRUD, message-level stats, or SMS from the same vendor and credential set.
• You want an officially maintained, vendor-supported SDK rather than a community wrapper: releases are active, the README is complete (auth, versioning, regional base URL, request/response contract), and the license is MIT — clean for commercial and redistributed use.
• You want to bring your own HTTP client for governance reasons (proxy egress, custom CA, connection pooling).
• You are comfortable owning a small internal service class / Laravel service provider around the client.

Look elsewhere or descope when:

• You only need to send mail. Laravel's Mail facade with SMTP credentials or Mailjet's SMTP relay requires zero custom code and no dependency. Reach for the SDK only when you need contacts, templates, stats, or SMS.
• You expect a native Laravel package. This is not one: no service provider, no facade, no publishable config, no MAILJET_* env wiring out of the box. Budget ~1–2 days to wrap it in a provider, config file, and a MailjetClient interface; if that overhead isn't acceptable, a maintained community Laravel wrapper is the pragmatic alternative.
• You need higher-level abstractions — queued batch sending, webhook/event ingestion, bounce handling, templating engines, rate-limit-aware retry. None of that ships here; you build it.
• You are on PHP < 8.1, or your stack pins an older Guzzle/PSR-7 that conflicts with the discovery mechanism.
• Adoption signal matters more than vendor backing. 274 stars and a reported 0 dependents is a thin community footprint for a widely used SDK — likely a metric artifact since most consumers use it directly per Mailjet docs rather than via Packagist graphs. Verify with composer why / Packagist stats and a spike before making it load-bearing; do not treat the star count as a proxy for reliability.
• You are pursuing a multi-ESP or failover strategy. A single-vendor SDK makes that harder; design the abstraction layer first, or choose a transport-agnostic approach (e.g., Symfony Mailer transports).

How to Pitch It (Stakeholders)

To executives (one paragraph): We can ship transactional and marketing email — password resets, receipts, notifications, campaign sends — on Mailjet's official PHP SDK. It is MIT-licensed, actively released, and maintained by the vendor, so we are not betting on an unmaintained open-source project. The integration cost is small: one dependency plus roughly one to two days of internal wrapping. Critically, it does not lock us in — the SDK sits behind a standards-based HTTP interface, so swapping providers later is a contained change, not a rewrite. Recommendation: adopt for the email channel, behind an internal interface, starting with transactional sends.

To engineering:

• Plain Composer package, PHP 8.1+, PSR-18/PSR-17 — no framework coupling, no global state, no service provider. We own the Laravel wiring: a config file, a singleton binding, and a thin MailjetClient interface. Estimate: 1–2 dev-days including tests.
• Bring our own Guzzle client so email traffic inherits existing timeout, proxy, retry, and telemetry configuration. Use force_ip_resolve => 'v4' if we see the documented SSL_ERROR_SYSCALL flakiness.
• Explicit API versioning matters: v3.1 for Send, v3 for contacts/templates/stats, v4 for SMS. Pin it in config, don't let it default implicitly.
• $CALL = false gives us a safe no-op client for CI and local dev — wire it to an env flag.
• The success() / getStatus() / getData() response contract is simple but non-throwing; we must translate non-2xx into our own exception and retry semantics rather than assuming failures surface automatically.

Risks and mitigations to state up front:

• Thin community footprint (274 stars, 0 reported dependents) → mitigated by official vendor maintenance, active releases, and a documented API contract; validate with a spike before making it load-bearing.
• No native Laravel integration → accepted; we build a small adapter, which also becomes our lock-in insurance.
• Vendor dependency for a critical path → abstract behind an interface from day one; keep a Symfony Mailer / SMTP fallback for pure-send paths so a provider outage or commercial change is survivable.
• Scope creep into marketing automation → the SDK gives primitives (contacts, lists, templates, stats), not workflows. Treat segmentation logic, drip campaigns, and preference centers as separate roadmap items with their own estimates.