- How do I install mvdnbrk/laravel-dhlparcel in a Laravel application?
- Install it with Composer by requiring mvdnbrk/laravel-dhlparcel, then publish the package config file with the vendor:publish command. Laravel's package auto-discovery registers the service provider and facade, so no manual wiring is usually needed. After publishing, add your DHL Parcel credentials, account number, and product codes to the config or your .env file. Be aware the declared Composer constraints target the Laravel 7/8 and PHP 7.x era, so installation on Laravel 10+ will likely require forking and relaxing the illuminate/* and guzzlehttp/guzzle constraints first.
- Does this package support Laravel 10, 11, or 12 and PHP 8.2+?
- Not out of the box. The last release was August 2020, which puts its Composer constraints in the Laravel 7/8 and PHP 7.x range, and those constraints will very likely block dependency resolution on Laravel 10, 11, or 12 with PHP 8.2+. In practice you should assume a fork is mandatory before the package lands in a modern application: bump or relax the illuminate/* and guzzlehttp/guzzle constraints, run the test suite, then validate against the DHL sandbox. Treat the fork as vendored source your team now owns rather than a maintained dependency.
- What functionality does laravel-dhlparcel actually cover?
- The package is a thin HTTP client wrapper over DHL Parcel's REST API and exposes a narrow surface: authentication, shipment creation, shipping label retrieval, and parcel tracking. It is not a full logistics domain layer, so cancellation, returns, and multi-carrier routing may not be covered and should be verified during your spike. Because the surface is small, it works well hidden behind an internal ShippingProvider contract with methods such as createShipment, getLabel, getTracking, and cancelShipment.
- Is mvdnbrk/laravel-dhlparcel still maintained?
- There is no evidence of recent maintenance: the last release was August 2020, the repository has roughly 18 stars, and the bus factor is one. There is no realistic upstream path for CVE fixes or DHL API version bumps, so plan accordingly. Treat the code as vendored source you own, assign an internal owner for the fork, and budget their time. The package's apparent popularity reflects genuine demand for DHL Parcel integration in Laravel, not the quality or freshness of this implementation.
- How do I configure DHL Parcel credentials and account numbers?
- Configuration is handled through the publishable config file, which holds your DHL Parcel credentials, account number, and product codes, typically populated from environment variables. This is the main configuration burden of the integration, so keep those values out of version control. The package appears to be single-account by design, so multi-account or multi-tenant setups will need your own credential resolution layer or per-tenant config switching. Request DHL sandbox credentials on day one, since that procurement often takes longer than the code work.
- How does the package handle API errors, validation failures, and rate limits?
- Error semantics are unvalidated in this package and are a known risk with wrappers of this vintage, which often collapse API errors into generic exceptions. That makes partial-failure handling, such as a shipment created but the label generation failing, hard to reason about programmatically. Inspect the exception taxonomy before committing and catch package exceptions at your adapter boundary, translating them into your own domain-specific error types. Verify rate-limit behaviour against the DHL sandbox rather than assuming retry semantics exist.
- Can I test this package without hitting the live DHL API?
- The package is a thin Guzzle-based HTTP client rather than a Laravel HTTP client wrapper, so it may not integrate directly with Laravel's Http::fake out of the box. You can still test your own adapter layer by mocking the package's client or by injecting a fake implementation of your internal ShippingProvider contract. For real confidence, run contract tests against DHL's sandbox environment to confirm endpoints, auth, and payload shapes. Do not assume meaningful test coverage ships with the package; verify it in the repository first.
- How are shipping labels returned, and where should I store the PDF?
- Label generation returns binary or PDF payloads, so first confirm whether the package streams, stores, or simply returns the label content. That answer determines whether you need a storage abstraction, a signed-URL delivery path, and a retention policy for label documents. Persist shipments and label references in your own table with your own status enum rather than relying on the package's response objects as a system of record. Keeping labels in your own storage layer also makes switching providers later far cheaper.
- Should I use this package or write my own DHL Parcel integration?
- Use it as an adapter, not as a domain dependency. Define an internal ShippingProvider interface covering create, label, track, and cancel, and let this package be one implementation behind it; that single decision converts most of the staleness and maintenance risk into a bounded, swappable cost. If your roadmap includes multi-carrier support, model this as one provider among several from day one. For anything beyond Benelux and DHL Parcel coverage, expect to integrate additional carriers alongside it.
- Which DHL Parcel API version does this client target, and is it still current?
- This is unverified and is the first question your technical spike must answer. DHL Parcel has evolved its endpoints and authentication model over the past five years, and a package last released in 2020 may target a superseded version. Check the client's request paths and auth scheme against DHL's current Parcel API documentation, then confirm with a real call to the sandbox. If the API has drifted, budget for adapting the fork rather than assuming the wrapper still works.