Lara Termii Laravel Package

Product Decisions This Supports

• Build vs. buy for messaging/OTP: This package is the "buy" side of the decision — Termii handles delivery, routing, and (now) eSIM provisioning, so the team writes a facade call instead of building carrier integrations, retry logic, and sender-ID management. The PM decision is which channels and regions you commit to outsourcing.
• Whether to expand from notifications into connectivity as a product line: v1.3.0 adds a full eSIM sub-client (dataPlans(), createEsim(), purchasePlan(), qrCode(), profile(), usage(), planStatus(), esims(), countries()). That is enough surface area to prototype a travel-eSIM, roaming, or IoT/M2M offering without a second vendor onboard. This is a roadmap-level unlock, not a nice-to-have.
• Vendor consolidation: one API key and one base URL now serve both the messaging and eSIM products. Fewer contracts, secrets, and billing relationships to manage — a real argument for standardizing on Termii rather than adding a dedicated eSIM provider.
• Sequencing of the notification roadmap: the removal of sendMessageWithNumber() tells you the Number API is not live on Termii's v4 gateway despite being documented. Any roadmap item depending on per-number messaging should be re-scoped or deferred, not scheduled against this SDK.
• Release-risk posture: a method added in 1.2.0 is gone in 1.3.0. Low practical impact (it never worked), but it sets a precedent that minor versions can remove public methods. Plan for pinned versions and a changelog review step in the upgrade ritual, not blind composer update.

When to Consider This Package

Adopt when:

• The application is Laravel/PHP and already uses (or is evaluating) Termii as the messaging provider for African markets — SMS, OTP, and transactional notifications.
• You want both messaging and eSIM behind one credential and one integration, and prefer a thin, framework-native client over hand-rolled HTTP calls.
• Your team values a small, readable surface: a facade plus product-scoped sub-clients ($termii->esim()), typed exceptions like TermiiException::esimAuthenticationFailed(), and no public API churn — the 1.3.0 refactor moved internals into traits without breaking callers.
• You want fast time-to-prototype on an eSIM feature and can accept a single-vendor dependency while validating demand.

Look elsewhere when:

• You need multi-provider routing or failover (Twilio, Vonage, or an abstraction layer). This package is single-vendor by design.
• You are not on Laravel, or you need channels beyond Termii's catalog (email, push, in-app) under one interface.
• You require strict semantic-versioning guarantees or long-term support commitments. The 1.2.0 → 1.3.0 add-then-remove cycle is a yellow flag; vendor it or wrap it if you need stability.
• eSIM token lifecycle is business-critical. Bearer-token exchange is handled automatically, but caching, refresh, and expiry behavior are implementation details. If you are selling connectivity, ask for the retry/refresh semantics before committing.
• You need delivery analytics, webhook abstraction, or per-message cost reporting out of the box — this is a client, not an observability layer.

How to Pitch It (Stakeholders)

For executives: The vendor we use for SMS and OTP now ships an eSIM product through the same integration. In one release we gained ten new capabilities — data plans, eSIM creation, plan purchase, QR provisioning, usage and status — at effectively zero incremental integration cost, because it reuses our existing credentials. That opens a credible path to a connectivity revenue line (travel eSIM, IoT) without a new vendor contract or a new procurement cycle. The one removal in this release is a method that never worked against the live gateway, so there is no customer-facing impact.

For engineering: Upgrade is low-risk — the public API is unchanged, internals were reorganized into per-product traits (Concerns\Engage, Concerns\Sotel), which sets us up for future product sub-clients. Two action items: (1) grep for sendMessageWithNumber() and delete any call sites — it was added in 1.2.0 and removed here because Termii's v4 gateway 404s on sms/number/send; (2) pin the version and review changelogs on upgrade, since this release demonstrates that minor versions can drop public methods. New surface to evaluate: $termii->esim() with nine endpoints and a typed esimAuthenticationFailed() exception for token-exchange failures.

Bottom line: Adopt the upgrade, treat the eSIM sub-client as a funded spike rather than a shipped feature, and hold per-number messaging off the roadmap until Termii confirms the endpoint is live.