Netgsm Laravel Package

Product Decisions This Supports

• SMS/notification channel build-vs-buy. This package is the "buy" side of the decision for Turkish-market SMS: instead of your team writing and maintaining a NetGSM REST client, the package owns the API contract, payload shaping, and response parsing. The PM decision is whether SMS is a core differentiator (build/own) or a commodity delivery channel (adopt the package).
• Delivery-report and auditability features. The 5.3.0 fix — returning the report jobId as a string rather than casting it to an integer — directly supports any roadmap item that depends on reliably reconciling "SMS sent" with "SMS delivered." Job IDs are opaque vendor identifiers, not numbers you do math on; preserving them as strings eliminates a class of silent mismatch, overflow, and truncation bugs in reporting dashboards, retry logic, and customer-facing delivery receipts.
• Reliability/trust work on messaging. If your roadmap includes delivery guarantees, retry-on-failure, or per-message status tracking, this release is a small but real upgrade: report lookups keyed on a mangled ID are a common source of "the SMS says delivered but our system says pending" support tickets.
• Vendor-integration surface area. Using this package keeps the NetGSM integration to a thin, upgradeable dependency with a small public API (send, bulk send, report/status), which makes it easier to price and schedule vendor changes (credential rotation, sender-header changes, API version bumps) as small tickets rather than projects.
• Data-model decisions downstream. Because the identifier is now a string, PMs should confirm that any schema, export, CSV, or analytics pipeline consuming jobId stores it as text. This is a cheap change now and an expensive one after a few hundred thousand rows land in an INT column.

When to Consider This Package

Adopt when:

• You operate in or send to Turkey and already use (or are evaluating) NetGSM as your SMS gateway.
• You're on a Laravel codebase — the package's value is largely in the framework-native configuration, service container binding, and idiomatic usage; on Symfony, plain PHP, or a non-PHP service you lose most of that benefit and should call the NetGSM API directly.
• Your SMS needs are transactional and volume-based (OTP, order/shipping updates, appointment reminders, bulk campaigns) rather than rich multi-channel orchestration.
• You want delivery reporting without owning the parsing quirks of the vendor's response format.

Look elsewhere when:

• You need multi-provider failover or channel abstraction (SMS + push + email + WhatsApp) behind one interface — a gateway-abstraction layer is a better fit than a single-vendor client.
• You're outside the Turkish market or already standardized on Twilio/Vonage/SNS; NetGSM-specific integration buys you nothing.
• You require inbound SMS handling, two-way conversations, or rich media — confirm the package's coverage matches; a thin client typically exposes outbound send plus reports.
• You need vendor SLAs, support contracts, or audit/compliance attestations — those come from NetGSM the vendor, not from the package, and the package being community-maintained means upgrade timing is on your team.
• Your compliance posture demands you own the consent/opt-out ledger end-to-end (e.g., Turkish İYS obligations); the package sends messages, it does not manage consent.

How to Pitch It (Stakeholders)

For executives (one paragraph): We use a small, focused Laravel library to send SMS through NetGSM, our Turkish SMS gateway, rather than maintaining that integration ourselves. The latest release (5.3.0) is a targeted correctness fix: when we ask NetGSM for a delivery report, the job identifier now comes back as a string instead of being forced into a number. That sounds minor, but it removes a known failure mode where long or oddly formatted vendor IDs get corrupted and our delivery tracking silently disagrees with the carrier. No new features, no configuration changes, and no change to how we call the library — it's a low-risk patch that improves the accuracy of the delivery data our support and ops teams rely on.

For engineering (summary):

• Change: report jobId is now returned as string instead of being cast to int (PR #53, released as 5.3.0).
• Why it matters: vendor job IDs are opaque tokens. Integer casting risked overflow/truncation and lost leading characters, producing report lookups that fail or match the wrong job.
• Upgrade risk: low at the library boundary — but treat it as a type-contract change. Any of our code that type-hints int, does arithmetic/comparison on the ID, or persists it into an integer column will need review. Audit consumers, switch DB columns and casts to string, and update tests that assert an integer.
• Action: bump the dependency, run the messaging test suite, and grep for jobId usage in our reporting and retry paths before deploy.
• Ongoing ownership: this is a single-vendor integration. Track NetGSM API version changes and the package's release cadence; keep our wrapper thin so swapping providers remains a contained effort.