Sdk Laravel Package

Product Decisions This Supports

Build vs. buy on the shipping/fulfilment integration. The core question this package answers is whether to hand-roll MyParcel API calls or adopt a maintained client. Since the API surface is non-trivial (shipment creation, carrier-specific delivery options, pickup locations, label PDFs, track & trace), a vendor SDK converts a multi-sprint integration into an evaluation-and-wiring exercise. Treat "buy" here as "adopt + wrap," not "adopt raw."

Which shipping capabilities are in scope for v1. The package's feature list maps cleanly to a scoping exercise. Label PDF generation, track & trace retrieval, and delivery-option/pickup selection are three separable capabilities — decide whether v1 ships all three or starts with labels + tracking and defers pickup-point UX (which implies a map/modal UI and address validation, i.e., front-end cost, not just integration cost).

Roadmap sequencing for Benelux/EU expansion. MyParcel is oriented toward Netherlands/Belgium carrier networks (PostNL, DHL, DPD-class options). If the product roadmap includes Benelux shipping, this is a fast path. If roadmap is domestic-only or non-EU, this is a distraction. Let the market roadmap drive the decision, not the SDK's convenience.

Carrier abstraction strategy — the decision with the longest tail. This is a single-carrier client with structured responses, not a rate-shopping or multi-carrier orchestration layer. Decide now whether the product will need multiple carriers within 12–18 months. If yes, budget for an internal ShippingGateway interface that this SDK sits behind, so a second carrier doesn't force a rewrite of checkout/order-admin code. If no, wrapping is still cheap insurance.

Checkout delivery-option UX. "Manage delivery options and pickup locations" is really a product feature decision: do we expose pickup points and delivery-date selection to buyers? The SDK makes the data reachable, but the conversion impact and UI cost are product calls, not engineering ones.

Operational tooling for CS and warehouse. Track & trace plus PDF label retrieval supports an internal order-admin capability (reprint label, resolve "where is my parcel"). Worth sizing as a support-cost-reduction line item rather than pure engineering output.

Which version line we integrate against. The v12 line is in beta (latest tag: 12.0.0-beta.3). Betas on a fulfilment-critical dependency mean the API can move under you between patch releases. The decision is not "latest version" but "integrate against the newest stable line and track v12 as a future migration" — and budget a small spike later to assess the v12 breaking changes once a changelog exists.

Due-diligence gates before commitment. Two of the three original unknowns have moved, one has not:

• Repository / ownership — partially resolved. Releases now reference github.com/myparcelnl/sdk. The organisation name matches the vendor, which is consistent with a first-party SDK rather than an anonymous third-party wrapper, but ownership, maintainer activity, and issue responsiveness still need a five-minute look before we call maintenance risk "low."
• License — unresolved. Still NOASSERTION rather than a recognized SPDX identifier. Legal review remains mandatory; this gate has not moved.
• Release metadata — still anomalous, now confirmed across two data points. The release dates remain in the future (2026-10-16), and the beta.3 body is empty — no changelog, no diff summary, no breaking-change note for a major version bump. Treat release dates and release notes from this source as unreliable signals. For v12 you will have to read commits to know what changed.
• New gate: changelog discipline. An empty release note on a major-version beta is a process signal. It doesn't block adoption, but it means upgrade planning is manual and should be time-boxed accordingly.

When to Consider This Package

Adopt it when:

• MyParcel is already the chosen carrier relationship (contract, rates, account), and the question is purely how to integrate.
• The stack is PHP — Laravel specifically benefits, but the package is framework-agnostic, so a thin service-provider wrapper is sufficient.
• You need labels, track & trace, and delivery options in weeks rather than quarters, and shipping is a supporting capability rather than the product's differentiator.
• Volume is modest-to-moderate and you are not yet doing complex rate shopping, multi-warehouse routing, or carrier failover logic.
• You can tolerate vendor-coupled integration code, provided it is isolated behind an internal interface.
• You pin to a stable release line and treat v12 as a planned later migration, not the entry point.

Look elsewhere when:

• You need multi-carrier orchestration. Rate comparison, automatic carrier selection, failover, and normalized tracking events across carriers are not what this does. A shipping-aggregation layer or internal abstraction is the better buy.
• Licensing is a blocker. NOASSERTION means the terms are not machine-recognizable. Legal review is mandatory before shipping it in a commercial product; if legal cannot clear it, stop here. Nothing in the new release changes this.
• Maintenance confidence is required. Low star count, an unverified repository/ownership story, empty release notes on a major beta, and future-dated releases are weak signals for a dependency that will sit on your critical path to fulfilment. If the business cannot absorb a fork-and-own scenario, prefer a vendor-supported integration or an in-house thin client against the documented API.
• You would need to start on the beta line. If the stable line is unusable for your use case and only 12.0.0-beta.x exposes the features you need, that is a signal to wait rather than a signal to adopt early.
• You need a first-class Laravel package — config publishing, facades, queues, events, webhook handling, testing fakes. This is "framework-agnostic PHP client," so you build that ergonomics layer yourself. Budget for it.
• Your shipping is genuinely simple (one carrier, one service level, no pickup points). Raw HTTP against a handful of endpoints may be less total surface area than learning an SDK you must also wrap and audit.
• You need SLA-backed support or compliance artifacts (SOC2, DPA specifics) that a low-visibility package cannot provide.

Decision rule: if shipping is a supporting capability, MyParcel is the committed carrier, and legal clears the license — adopt the latest stable line with an abstraction wrapper and a pinned version. Do not let a v12 beta set the integration timeline. Otherwise, defer.

How to Pitch It (Stakeholders)

For executives (one paragraph): MyParcel is a shipping-API integration that would otherwise cost us several sprints of custom HTTP work. This package is a ready-made PHP client covering the four things we actually need — create shipments, generate PDF labels, fetch track & trace, and expose delivery/pickup options. It reduces time-to-market for Benelux shipping from a build project to an integration-and-wrap task, and it lets us route this through our existing Laravel stack without new infrastructure. The dependency picture is now somewhat clearer: releases point to a GitHub repository under the vendor's own organisation name, which is consistent with a first-party SDK. Two caveats remain — the license still has no recognized designation, so legal must clear it, and the current major version is in beta with no published changelog, so we would integrate against the stable line and treat v12 as a future migration. Net: faster to market, low switching cost if we isolate it behind our own interface.

For engineering (the ask): Wrap, don't scatter. (1) Define an internal ShippingGateway interface and make this SDK one implementation; no controller or model should import SDK classes directly. (2) Pin to the latest stable tag with a locked dependency — do not float, and do not start on 12.0.0-beta.x; track v12 separately and read the commit log rather than the release notes, which are empty. (3) Put it behind queued jobs for label generation and tracking sync — label PDFs are the slow, failure-prone call. (4) Add a testing fake at the interface boundary so CI never hits the live API. (5) Persist labels and tracking payloads locally; treat the carrier as source-of-truth-but-not-storage. (6) Confirm the license terms and verify that myparcelnl/sdk is genuinely vendor-maintained (who can merge, how fast do issues close) before we go past a spike.

Explicitly not claimed: that this is a supported, officially maintained, or widely adopted package. The evidence available (31 stars, NOASSERTION license, empty release notes on a major beta, future-dated releases) does not support that claim, and we should not present it to stakeholders as if it does. The vendor-organisation repository is a positive signal, not a guarantee. The pitch is speed-to-integration with bounded, deliberate dependency risk — not vendor endorsement.