Mygls Sdk Laravel Package

Technical Evaluation

Architecture fit. webapix/mygls-sdk is a framework-agnostic, lightweight PHP wrapper over the MyGLS (GLS logistics) REST API. That is the right shape for Laravel: it should sit behind your own domain interfaces (LabelService, TrackingService, PickupPointService) and be bound in a service provider, never called directly from controllers or models. The SDK provides convenience (auth, request building, DTOs) but no domain model of its own, so the real architecture decision is yours, not the package's. Verdict: acceptable as a contained adapter for a GLS-only shipping flow in GLS markets (HU/CZ/SK/RO/HR/SI/RS and similar); not acceptable as a foundation for a multi-carrier logistics platform without an abstraction layer around it.

Integration feasibility. Composer-installable, MIT-licensed, small surface area. A competent Laravel developer can get label creation and tracking working against a sandbox in days, not weeks. The unknowns are packaging hygiene rather than conceptual difficulty: PHP version constraints, whether it uses PSR-18/PSR-7 or hard-depends on a specific Guzzle major (which can collide with Laravel's HTTP client stack), whether responses are typed DTOs or raw arrays, and whether errors are a coherent exception hierarchy or generic throws. Those determine whether integration is a 3-day spike or a 3-week rework.

Technical risk — material.

• Provenance gap. The repository is recorded as unknown, and the only identifier is a Packagist-style name. You cannot approve this dependency until the actual source repository, maintainer identity, and Packagist record are verified and pinned.
• Release metadata anomaly. "Last release: 2026-09-21" is a future date relative to any normal evaluation window. This is either a metadata error or a fabricated/backdated tag; either way it invalidates the freshness signal and must be resolved before you use release cadence as a health metric.
• Unofficial + low adoption. 29 stars and a single-maintainer profile imply bus factor 1, no SLA, no deprecation channel, and no contract tests against the live API. GLS can change endpoints and this package simply breaks.
• Operational blast radius. Label creation is a money- and fulfillment-critical operation: duplicate labels cost real money, failed labels stop shipments, and malformed labels stall warehouse printers. This is not a "nice-to-have wrapper" category of dependency.
• Legal/terms. "Unofficial" may conflict with GLS API terms or partner agreements. Confirm your GLS contract permits third-party clients.

Key questions to answer before approval.

1. What is the actual source repository, and is the Packagist vendor/name authentic and consistently published? Any install scripts, binary blobs, or telemetry?
2. Is MyGLS the correct API surface for our GLS contract, or do we need a different GLS product/partner API?
3. Coverage: label create/print/cancel/reprint, PDF/ZPL/PNG formats, multi-package, COD, declared value, returns, pickup-point/parcel-shop lists, tracking/status, daily manifest or pickup booking?
4. Auth model (basic vs. token), token lifetime, rate limits, idempotency semantics for label creation?
5. PHP/Laravel version support, PSR-18 compliance, transitive CVE surface, and presence of tests/CI/static analysis?
6. Error taxonomy: retryable vs. terminal, and are raw API error codes surfaced?
7. Maintainer responsiveness: median issue/PR response time, and has a security issue ever been handled?
8. Does the SDK log credentials or customer PII?

Integration Approach

Stack fit. Laravel-native integration is straightforward: publishable config, credentials from a secrets manager (not committed .env), a singleton client binding, and a thin anti-corruption layer that maps SDK responses to your own shipment DTOs. Use Laravel's HTTP client or the SDK's PSR-18 client with explicit timeouts, a retry policy for 5xx/429 only, and structured logging with correlation IDs.

Migration path.

1. Shadow mode first. Generate labels through the SDK and tracking lookups in parallel with your current process (manual portal or existing provider), compare outputs, and do not dispatch from SDK-generated labels until parity is proven over a representative sample (multi-package, COD, international, oversized).
2. Strangler pattern. Put the SDK behind the same interface as the incumbent so a feature flag can switch traffic per carrier/region and roll back in minutes.
3. Fork-ready. MIT permits an internal fork. Assume you will need it; keep the adapter thin so a fork swap is a namespace change, not a rewrite.

Compatibility. Pin an exact version with a committed lockfile — no dev-master, no floating constraints. Verify PHP 8.2/8.3 and Laravel 10/11/12 support, and specifically check Guzzle major-version conflicts with Laravel's HTTP client. Run composer audit in CI and add the package to Dependabot/Renovate with an internal owner.

Sequencing (recommended).

• Week 1 — Due diligence spike (2–3 days): verify provenance, composer audit, authenticate against sandbox/production-test, create one label, cancel it, fetch one tracking status. Produce a go/no-go memo.
• Week 2 — Adapter + contracts: domain interfaces, DTO mapping, error taxonomy, recorded fixtures, mocked tests. No live calls in unit tests.
• Week 3 — Persistence & idempotency: shipments and labels tables, unique constraint per order/parcel, idempotency key strategy, label PDFs in object storage (S3) not the database, retention policy.
• Week 4 — Async & observability: queued label creation and status polling with exponential backoff and dead-letter handling; dashboards for label success rate, p95 latency, error-code distribution, auth failures.
• Week 5 — Parallel run & cutover: shadow mode, reconciliation job for orphaned labels, then flag-gated cutover.

Operational Impact

Maintenance. This is the dominant risk. Assume low upstream activity: budget a named internal owner and roughly 1–3 engineer-days per quarter for dependency bumps, GLS API changes, and patches. Establish a staleness policy — if upstream has no release or issue response for 6–12 months, schedule replacement (either a maintained fork or a direct HTTP client you own). Track the future-dated release anomaly as an open governance item until resolved.

Support. No vendor support; GLS support will not debug third-party SDK issues. Escalation is best-effort GitHub issues plus your internal owner. Critical runbook requirement: a documented manual fallback — print labels directly in the MyGLS web portal — so a broken SDK never blocks the warehouse. Document credentials rotation and the exact error codes that mean "call the portal."

Scaling. The bottleneck is GLS rate limits and per-request latency (typically hundreds of milliseconds to a few seconds per label), not PHP. Queue everything, cap concurrency per GLS account, and use a circuit breaker so an GLS outage degrades gracefully instead of saturating workers. Store label artifacts in object storage with lifecycle rules. Q4 peak is the real test: run a load rehearsal at expected peak ×2 before November, and pre-provision queue workers.

Failure modes to design for.

• Credential expiry / auth lockout → total label outage; monitor with an active synthetic label-cancel probe, not just passive error rates.
• Timeout after server-side success → orphaned labels and double-charging on retry; require reconciliation sweeps by date range and a "label exists?" lookup before retry.
• Duplicate label creation → enforce idempotency keys and a DB unique constraint, not application logic alone.
• Address/COD validation rejections → validate pre-submit to avoid queue churn.
• API version deprecation → silent breakage; run contract tests against the sandbox nightly.
• Label format/printer mismatch (PDF vs. ZPL) → warehouse delay; certify each printer model once.
• PII/credential leakage in logs → audit the SDK's logging and scrub at the adapter boundary.
• Supply-chain compromise via an unmaintained package → lockfile, audit CI, and a policy that only the internal fork is deployable.

Ramp-up. A mid-level Laravel engineer needs roughly 1–2 days to learn the SDK surface (it is small) and about a week to be productive on the adapter, tests, and runbooks; a second engineer needs half a day for on-call readiness. TPM-level effort is front-loaded into due diligence: provenance verification, GLS contract/terms confirmation, and a written risk acceptance for adopting an unofficial, low-adoption dependency. Given the composite score (~18.6/100), treat this as a high-risk, narrowly-scoped dependency: approve only inside an adapter with a manual fallback, an internal owner, and a scheduled review date — do not let it become load-bearing infrastructure.