Elasticemail Php Laravel Package

Product Decisions This Supports

• Email Infrastructure Consolidation: Replace fragmented email-sending logic (e.g., SMTP, third-party APIs) with a unified, scalable solution for transactional and bulk emails.
• Duplicate-Send Elimination (new in 4.4.0): Idempotency keys on all three send endpoints (/emails/transactional, /emails, /emails/mergefile) let us safely retry a send after a timeout or dropped connection without a customer receiving — or being billed for — the same email twice. This turns "retry" from a support-ticket generator into a supported product behavior.
• Billing & Cost Predictability: Because a replayed send returns the original TransactionID/MessageID and is not charged again, per-send cost forecasting no longer needs a "retry buffer" margin. Replaces the manual de-duplication tables many teams keep today.
• Marketing Automation Integration: Enable programmatic campaign management (e.g., A/B testing, scheduling) for marketing teams without manual UI reliance.
• Data-Driven Personalization: Leverage contact segmentation, event tracking, and analytics to refine email strategies (e.g., dynamic content, re-engagement flows).
• Cost Optimization: Replace high-cost SMTP providers or legacy systems with a pay-as-you-go model (ElasticEmail’s pricing).
• Roadmap Priorities:
  • Phase 1: Replace ad-hoc email scripts with the package for transactional emails (e.g., password resets, notifications), generating a UUID v4 idempotency key per logical send and persisting it alongside the outgoing job so retries and queue redeliveries reuse the same key.
  • Phase 2: Migrate marketing campaigns to ElasticEmail’s API for analytics and automation; use idempotency keys on mergefile imports so a re-run after a partial failure doesn’t double-send to a segment.
  • Phase 3: Build a self-service portal for non-technical teams to manage lists/campaigns via the API.

When to Consider This Package

• Adopt if:

  • Your PHP stack already uses Laravel/Symfony and needs a native email API integration.
  • You send from queued jobs, webhooks, or any at-least-once delivery path where a retry could duplicate a customer-facing email or double-charge (4.4.0 directly addresses this).
  • You send >10K emails/month and want to avoid SMTP rate limits or per-message costs.
  • You require campaign analytics, contact segmentation, or bulk uploads (CSV/JSON).
  • Your team lacks SMTP expertise but needs reliable deliverability (ElasticEmail handles warming, IP rotation).
  • You’re building a SaaS product with multi-tenant email needs (API keys per client), where per-account idempotency scoping keeps tenants isolated.

• Look elsewhere if:

  • You need low-latency (<100ms) email delivery (ElasticEmail’s API has 600s timeout limits).
  • Your use case is high-volume (>1M emails/day); consider dedicated SMTP or a hybrid approach.
  • You require advanced templating (e.g., interactive HTML emails); ElasticEmail’s templates are basic.
  • Your team prefers serverless (e.g., AWS SES) or open-source (e.g., Mailgun’s PHP SDK) solutions.
  • You’re constrained by budget: ElasticEmail’s pricing starts at $15/month (vs. free tiers from competitors).
  • You upgrade to 4.4.0 on any code that passes $contentType positionally to the three send methods — the new $idempotency_key argument sits in front of it and that call will now break. Budget a dependency audit before pinning the version. (Calls with just the payload are unaffected.)

How to Pitch It (Stakeholders)

For Executives:

"This package lets us replace our patchwork of SMTP providers and manual email tools with a single, scalable API for all customer communications—transactional, marketing, and notifications. It cuts costs by ~30% vs. our current setup, adds analytics to measure campaign performance, and reduces support tickets from misconfigured emails. The new release adds an industry-standard safety net: if a send times out, we can retry it and the customer still gets exactly one email and we're still charged exactly once. That removes a whole class of 'why did I get this twice?' incidents and the manual de-duplication workaround we'd otherwise have to build. For $15/month, we get deliverability guarantees, bulk uploads, and a self-service portal for marketing teams. ROI comes from higher open rates (via segmentation), lower churn (better notifications), and fewer duplicate-send refunds."

For Engineering:

*"The ElasticEmail PHP SDK is a drop-in replacement for our current email logic. It handles:

• Transactional emails: Replace Mail::send() calls with API calls for password resets, invoices, etc.
• Bulk campaigns: Send segmented emails to 10K+ users via CSV/JSON uploads (faster than SMTP).
• Analytics: Track opens/clicks in real-time via the API (no need to parse logs).
• Security: Centralize domain verification and API keys to prevent misconfigurations.

4.4.0 — idempotent sends:

• All three send methods (emailsTransactionalPost, emailsPost, emailsMergefilePost) take an optional $idempotency_key as the second parameter, plus matching ...WithHttpInfo, ...Async, ...AsyncWithHttpInfo, and ...Request variants.
• Semantics: same key + byte-identical body within 24h → stored response replayed (Idempotency-Replayed: true, same TransactionID/MessageID), nothing sent or charged. Same key + different body/endpoint → 422. Same key while in flight → 409 (back off and retry). Malformed key → 400. Unconfirmed key → 503 with Retry-After. 4xx/5xx releases the key so a corrected retry works. Keys are account-scoped (subaccounts separate) and expire 24h after first use.
• Implementation plan: generate a UUID v4 per logical send, persist it on the queued job row before dispatch, and reuse it across queue retries and manual requeues. Keys are not interchangeable across endpoints or bodies, so derive the key from the send record — don't hash-and-hope.
• Breaking change: $idempotency_key now precedes $contentType. Any call passing $contentType positionally must pass null first or switch to named arguments. Payload-only calls are unaffected. Audit before bumping.

Tradeoff: 600s timeout per request (but 20 concurrent connections allowed). We'll need to batch large exports. Docs are solid, but we'll need to wrap the SDK in a service layer for consistency — the idempotency-key lifecycle (generate, persist, reuse, expire) is exactly the kind of thing that belongs in that wrapper, not scattered across call sites."*

For Marketing:

*"No more begging devs for email changes! This API lets us:

• A/B test subject lines and schedule campaigns directly.
• Segment contacts (e.g., 'inactive users') and trigger re-engagement flows.
• Export reports to CRM tools via the API (no manual CSV downloads).
• Re-run a campaign safely: if a big send hiccups mid-import, we can relaunch it without blasting the first half of the list a second time.

Example: Launch a 'Summer Sale' campaign in 10 minutes—no UI training needed."*