Messagebird Notifications Laravel Package

Product Decisions This Supports

• Notification channel strategy. Decides whether SMS becomes a first-class delivery channel for transactional messaging — OTP/login codes, order and delivery updates, payment and account alerts — in a Laravel product that already treats Laravel Notifications as its outbound abstraction. This package is the transport glue for that decision, not the decision itself.
• Build vs. buy (and how much to buy). Frames the trade-off between adopting this narrow, MIT-licensed channel adapter and writing an in-house equivalent. The surface is genuinely small — a channel class returned from via() plus a toMessageBird() message builder — so the "buy" case is about speed to a first send, not depth of capability. With a credible internal-build fallback of roughly one to two engineering days, adoption has to be justified by schedule pressure rather than by features.
• Vendor selection and point commitment. Informs whether MessageBird (now Bird) sits alongside or replaces Twilio, Vonage, or AWS SNS for SMS. The package is vendor-specific by design and exposes no multi-provider abstraction, so choosing it is a point commitment to Bird for that channel — a procurement, pricing, and commercial-relationship decision as much as a technical one. The maintainer is not the vendor; a Bird contract with its own support tier is a separate line item.
• Roadmap sequencing and unblocking. Can pull SMS-dependent features forward (2FA rollout, transactional alerting, operational paging) without carving out a bespoke integration sprint — conditional on a diligence spike passing. That is a scheduling decision with a real option value: a two-day spike can de-risk a multi-week feature commitment.
• Unit-economics and cost modeling. Segment math (160 GSM-7 chars, 153 per concatenated segment; 70/67 for Unicode) and retry behavior are direct cost drivers. One emoji in an OTP flips the message to UCS-2 and can double the bill; naive queue retries turn a vendor 500 into duplicate charges. This package forces those decisions into the open early, which is useful even if the package itself is later replaced.
• Reliability and UX posture for authentication flows. Because the package does not handle delivery receipts, a 200 means "queued," not "delivered." That drives product decisions about multi-channel fallback (SMS and email on login/payment flows), resend paths, and timeout states — a "sent" indicator alone is not an acceptable 2FA experience.
• Geographic eligibility and sender-ID policy. Sender-ID rules vary by country; an alphanumeric originator that delivers to a UK handset may be dropped for a US one. Adoption implies a decision about which markets get SMS at launch versus email-only until local long codes are provisioned.
• Ownership and maintenance burden. With zero stars, zero dependents, a single maintainer, and a changelog that is just a commit link, adopting this is explicitly a decision to own an adapter, not to consume a supported product. That should be named as an owner, a review cadence, and a version-pinning policy, not left implicit.

When to Consider This Package

Consider it when:

• The product is on Laravel and already using Laravel Notifications as its outbound messaging abstraction; the integration cost is lowest where via() and Notifiable are already familiar.
• Bird/MessageBird is already chosen, in trial, or commercially under evaluation for SMS — the package does not help you decide the vendor, only to ship against one.
• The immediate need is a single, high-value transactional send: an OTP is the ideal first use case — one recipient, one short message, verifiable outcome on a real handset.
• The scope is genuinely narrow: outbound transactional SMS with a configurable access key and originator. No templating engine, no inbound, no receipts required at launch.
• Engineering can absorb a ~200-line adapter in a day and write its own tests. The source is the documentation; budget the first hour for reading, not coding.
• Speed to a first send matters more than depth of capability — for example, unblocking a 2FA launch date.

Look elsewhere when:

• The Laravel constraint does not fit. The description says Laravel 5.x. Verify composer.json ranges and the transitive messagebird/php-rest-api version before anything else. If it is 5.x-only, this is a fork-or-rebuild decision, not an integration task — and at this size, rebuilding is usually cheaper than backporting.
• You need delivery receipts, inbound messaging, multi-provider failover, or managed templating. None of that is here; you would be building it alongside, at which point use the Bird SDK directly or a maintained multi-channel package.
• Procurement requires an SLA, security review history, or vendor support — there is no issue history, no third-party validation, and no upstream to escalate to. You are the upstream.
• Engineering has no bandwidth to own an adapter indefinitely, including re-testing at every Laravel and MessageBird SDK upgrade. The real maintenance load is version drift in the SDK, not in this package's own code.
• Volume is high enough that cost control dominates. Segment math and retry discipline are your invoice, and a throwaway adapter with no cost guardrails will be expensive at scale.
• You are not prepared to gate SMS behind your own interface or feature flag. Without that seam, a provider swap touches every notification class instead of one binding.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed piece of glue that lets us send transactional SMS — starting with login codes — through Laravel's existing notification system, in days rather than a sprint. It costs nothing to license and carries no vendor lock-in beyond the SMS provider we choose, which is a separate commercial decision. The honest caveat is that it is an unmaintained micro-package: one author, no users, no changelog. The correct framing is not "adopt a dependency" but "adopt a 200-line adapter we will own." Recommended posture: a timeboxed spike behind a feature flag, pinned to an exact version, with a named internal owner and a one-binding swap seam. If the diligence spike passes, it unblocks a 2FA launch we would otherwise schedule weeks out; if it fails, the internal-build fallback is one to two days of engineering, so downside is capped.

For engineering: The integration surface is deliberately thin — return the channel class from via(), implement toMessageBird() returning the package's message builder, and provide routeNotificationForMessageBird() on the model. Expect three real risks: the Laravel version constraint (if it is 5.x, we fork or rebuild), env() calls in package source that silently break under config:cache, and ambiguity over whether the channel registers a 'messagebird' driver or is used by class name — pick one convention and apply it everywhere, because mixing them is the most common silent failure. The package throws a single exception type for all failures, so wrap it in our own decorator to distinguish permanent errors (bad number, blocked sender — fail fast) from transport errors (429/5xx — let the queue back off). Queue everything with an explicit retry budget and an idempotency guard; SMS costs money per attempt and duplicates are pure cost. Normalize phone numbers to E.164 at the model boundary and keep transactional copy ASCII and under 160 characters, asserted in a test. Notification::fake() proves our decision to notify, not delivery — the MessageBird SDK uses its own Guzzle client, so Http::fake() will not intercept it; bind a fake channel or inject a MockHandler. Plan to own delivery receipts and resend UX separately, since a 200 only means queued.