Laravel Mygls Laravel Package

Product Decisions This Supports

• Order fulfillment / shipping ops: generate GLS parcel labels, print them from the admin, and book courier pickups without leaving the Laravel admin — a concrete "ship it this sprint" capability rather than a roadmap line.
• Checkout & delivery promise: expose GLS services (home delivery, parcel shop / GLS Point) as selectable shipping methods, feeding delivery estimates at checkout.
• Post-purchase experience: pull tracking status into the order timeline and trigger "out for delivery" / "delivered" notifications, reducing "where is my order" contacts.
• Returns flow: issue reverse/return labels from the customer account area — a frequent driver of support cost.
• CEE market expansion: GLS is strong in Hungary, Slovakia, Czechia, Romania and Croatia; a single adapter can underwrite entry into several markets before local carrier negotiations.
• Build vs buy: this replaces roughly 2–6 sprints of in-house API client work (auth, label PDF handling, error taxonomy, sandbox quirks). Free (MIT) and Composer-installable, so buy wins on day one unless volume or compliance forces a custom layer.
• Multi-carrier strategy: use it as the first adapter to prove out an internal ShippingGateway abstraction before adding DPD, Foxpost, Packeta or an aggregator. The abstraction decision is the real product decision; this package is a cheap way to validate it.
• Commodity vs differentiator: treat carrier connectivity as plumbing. Product investment should go to delivery pricing, promise accuracy and comms — not to re-implementing label PDFs.

When to Consider This Package

Consider it when:

• You run a Laravel codebase (Composer-managed, PHP 8.1+) and GLS is a carrier you already or intend to use, especially in Hungary/CEE.
• Volume is low-to-mid (hundreds to low thousands of labels/month) — enough that per-label aggregator fees hurt, not enough to justify a logistics platform.
• The team is small (1–5 devs) with no dedicated integrations engineer.
• Your needs are the standard set: create label, print, track, cancel, book pickup.
• You want source you can fork and patch — MIT gives you that; a SaaS aggregator does not.
• You are comfortable owning the operational wrapper: queues, retries, idempotency, label storage, monitoring.

Look elsewhere when:

• You are not on PHP/Laravel — use the official GLS API or a carrier aggregator instead.
• You need vendor support, an SLA, a security questionnaire or a DPA. With ~17 stars, a single maintainer and no visible commercial backing, this will not clear procurement. Assume bus factor of one and plan to fork.
• You need rate shopping, address validation, customs paperwork, cross-border, or 3+ carriers on day one — a carrier aggregator (Shippo, Sendcloud, EasyPost or regional equivalents) is the better buy.
• Volume is high enough that webhooks, strict idempotency, delivery guarantees and observability are hard requirements; you will build those around this package regardless.
• You need WMS/ERP integration, EDI, label reprint audit trails or multi-warehouse routing.
• Your commerce platform (Shopify, Unas, Business Central, SAP) already ships a native MyGLS connector — don't duplicate.

Diligence before adoption: check test coverage and CI, open issues and last-commit cadence, supported Laravel/PHP versions, whether it targets the current official GLS REST API, and whether credentials/sandbox handling is config-driven. Pin the version, wrap it behind your own interface, and keep a documented fallback path.

How to Pitch It (Stakeholders)

For executives (30 seconds): "We can turn on GLS shipping — labels, tracking and pickup booking — inside our existing Laravel store for roughly one to two developer-weeks and zero license cost, versus an estimated four to six weeks to build it ourselves. At current order volume it pays back in the first month. The code risk is low; the maintenance risk is moderate — it's a small open-source project with one primary maintainer. We mitigate that by keeping it behind our own shipping interface, pinning the version, and retaining a documented fallback to GLS directly or a paid aggregator. Decision requested: approve as our v1 carrier integration for the Hungarian/CEE market, with a review trigger at ~5,000 labels/month or when we add a second carrier."

For engineering:

• Laravel-native: service provider, publishable config, facade — composer require, no sidecar service, no new infrastructure.
• Integrate behind a ShippingGateway contract; no package classes in domain code. That keeps the exit cheap if the package is abandoned or we outsource to an aggregator.
• We own the hard parts: queue label creation, store label PDFs and tracking IDs, enforce idempotency on retries, map vendor error codes to our own, and add alerting on failed label creation.
• Contract-test against the GLS sandbox in CI; keep one real-label smoke test per release.
• Ship as a thin v1 (create label + tracking), then add returns and checkout method exposure once the abstraction proves out.

Bottom line: a cheap, low-commitment enabler for CEE fulfillment — adopt it deliberately, isolate it architecturally, and treat the maintainer risk as a known, budgeted cost rather than a surprise.