Sendchamp Laravel Package

Technical Evaluation

Architecture fit

• Follows standard Laravel package conventions (service provider with auto-discovery, publishable config, facade) and drops cleanly into a Laravel app's dependency graph.
• Real value depends entirely on whether it ships a Notification channel driver. If it does, it plugs into Notifiable / via() cleanly. If it is only a facade over Http::withToken(), it is a thin wrapper we could replace with ~30 lines of first-party code.
• It is single-vendor by design: the abstraction is Sendchamp-shaped, not a provider-agnostic gateway. Adopting it at the framework-extension layer bakes in a vendor coupling we would later have to invert.

Integration feasibility

• Mechanically trivial: composer require, publish config, set credentials in .env. No infrastructure, no schema, no background worker required beyond our own queues.
• Two gating items carry the real cost: (1) version constraints — a 2022-era release likely targets Laravel 8/9 and PHP 8.0; on Laravel 11/12 composer resolution may fail, forcing a fork; (2) endpoint coverage — SMS, WhatsApp templates, verification/OTP, sender-ID management, delivery receipts and webhooks are distinct surfaces, and there is no evidence the package covers all of them.

Technical risk

• High for any revenue- or compliance-critical path. Last release Oct 2022; ~3 years without a release in a fast-moving third-party API is the dominant risk. Sendchamp's API and payload shapes may have drifted with no corresponding package change.
• Unvalidated in practice: 5 stars, 0 dependents, single maintainer. No public production usage to lean on, so we would be the first set of eyes on the code.
• No visible quality signal: no evidence of CI, test suite, static analysis, or security review. Treat every code path as unverified until we test it.
• Lock-in by omission: swapping providers later means touching every call site unless we wrap it. Supply-chain review is on us.

Key questions

1. Does it register a Laravel Notification channel, or is it only a static facade?
2. Which endpoints does it cover, and against which Sendchamp API version — current or a superseded one?
3. What is the actual composer.json PHP/Laravel matrix, and has it been verified on ours?
4. Last commit vs. last release — is there unreleased work, or is the repo dormant?
5. Does it implement timeouts, retries/backoff, idempotency keys, and rate limiting, or does it surface raw Guzzle exceptions?
6. Does it verify webhook signatures and model delivery-status callbacks?
7. Is the vendor dependency acceptable — Sendchamp account, KYC, sender-ID approval, and geographic coverage for every country we message?

Integration Approach

Stack fit

• Good syntactic fit for a Laravel monolith that sends through queued jobs and Notifications. Poor fit if messaging is a shared, multi-provider, multi-country platform capability.
• Recommend adopting it only behind an internal contract (e.g. MessagingGateway) rather than calling the facade from domain code. That preserves a swap path and a kill switch.

Migration path

1. Timeboxed spike (≈0.5 day): install in a scratch app, resolve against our PHP/Laravel matrix, hit sandbox endpoints, diff exposed methods against our required endpoint list.
2. If coverage and compatibility hold → fork under our namespace (MIT permits it). Upstream is dormant; we should own bugfixes and API drift explicitly rather than hope for releases.
3. If coverage has gaps or is materially stale → drop the package. The API is plain REST/JSON; a first-party client on Laravel's Http facade is ~2–3 days and removes a dependency, a bus factor, and a version constraint simultaneously. This is the likely outcome given the maturity signals.

Compatibility

• Pin an exact version, commit the lockfile, and run the dependency against our full CI matrix. Anything not exercised in CI is untested code.
• Verify php artisan config:cache behavior, env-var naming collisions with an existing Sendchamp integration, and behavior under multi-tenant credential sets if that applies.

Sequencing

1. Vendor decision first — confirm Sendchamp commercially and start account/KYC/sender-ID registration. This is the longest lead item and is independent of the package.
2. Compatibility + endpoint-coverage spike.
3. Wrap behind the internal contract; write contract tests against the Sendchamp sandbox.
4. Route all sends through queues with a send-path adapter and feature flag.
5. Add webhook ingestion and delivery-status reconciliation.
6. Only then expose to product features (OTP, notifications, transactional SMS).

Operational Impact

Maintenance

• We own this. Dormant upstream means API drift, dependency bumps, and bugfixes land on our platform team. Budget ~1–2 days per quarter plus incident-driven patching, and name a single owning team for the fork.
• Add it to software composition analysis and manual review lists; expect no CVE feed or deprecation notices upstream.

Support

• Effectively none: one maintainer, 5 stars, 0 dependents, no SLA, no triage history. There is no escalation path for a production outage beyond the Sendchamp vendor's own support — evaluate their SLA separately, because that is the only support that matters here.

Scaling

• Package overhead is negligible; the ceiling is Sendchamp's throughput, rate limits, and per-message pricing. Ensure all sends are queued with backpressure, bulk SMS is batched, and per-account concurrency caps are enforced client-side.
• Cost model (per-message pricing, NGN currency exposure, WhatsApp conversation pricing) needs a finance owner; this is a commercial scaling risk, not a technical one.

Failure modes

• Timeouts and 5xx with no retry/backoff → silently dropped messages.
• No delivery-receipt consumption → we believe a message was delivered when it was not; needs polling or webhook reconciliation.
• Unhandled HTTP exceptions surfacing raw provider payloads into logs or user-facing errors — PII exposure of phone numbers under NDPR/GDPR.
• Unverified webhooks → replay and forgery of delivery status.
• Unpinned API version drift → payload shape changes break production with no package update.
• Config-cache/env misconfiguration across deploy targets; rotated API keys with no health check.

Ramp-up

• Code ramp-up is trivial: a Laravel developer can send their first message in under an hour from docs alone.
• The real ramp-up is domain and calendar time: sender-ID approval lead times, NCC/DND compliance for Nigerian numbers, WhatsApp template pre-approval cycles, message-length/Unicode encoding cost mechanics, and delivery-receipt semantics. Plan 1–2 weeks of calendar time for account, KYC, and compliance before the first production message — that, not the package, is the critical path.