Dpd Client Laravel Package

Technical Evaluation

Architecture fit webit/dpd-client is a thin transport/SDK layer over DPD's carrier web services (historically SOAP/WSDL, Polish market endpoints) covering parcel creation, label generation, pickup ordering, and tracking. That is the right shape for a carrier integration — it should never be the architecture, it should be a swappable adapter behind a domain port. The package is a generic PHP library with at best a thin Laravel service provider/facade; it carries no domain model. Treat it as an implementation detail of a ShippingProvider boundary, not as a component your order/fulfilment code imports directly.

Integration feasibility Feasible but non-trivial. Expect: SOAP extension dependency, credential set (login/password/master FID or equivalent), sandbox vs production WSDL endpoints, and label output as binary PDF to be streamed or persisted to object storage. Happy-path single-parcel label generation is a day or two of work. The tail is longer: cash-on-delivery, DPD pickup points, return labels, international consignments, and multi-parcel shipments each carry their own payload fields and validation rules that a 2019-era wrapper may not model correctly. The lack of any test suite or sandbox fixtures in the package means you will be reverse-engineering DPD's fault messages to discover edge cases.

Technical risk The dominant risk is abandonment, not code quality. Last release 2019-05-29, 3 stars, 0 dependents, low composite score — there is effectively zero community validation and no maintenance path. Concretely:

• Composer constraints almost certainly pin symfony/* and/or guzzlehttp/* to versions that conflict with Laravel 9/10/11. Expect a hard dependency conflict, not a soft one.
• The code predates PHP 8.x; nullable/type coercion and deprecated syntax may warn or fatal.
• Transitive dependencies are frozen and unpatched — no security disclosure channel exists for this package.
• DPD has been moving toward REST/JSON alongside legacy SOAP; the wrapper will lock you to whatever WSDL vintage it was written against.
• MIT license means you may fork; the license is the only thing that makes this package usable at all.

Key questions

1. Which DPD operating company and API contract does this target — Poland SOAP, or a market with a REST API? Does it cover label, pickup, tracking, COD, returns, and international, or only parcel creation?
2. What are the exact composer.json constraints for php, illuminate/support, symfony/*, ext-soap? Does it install cleanly on our target Laravel/PHP version?
3. Is there a DPD sandbox/test environment with credentials, and does the package support endpoint switching?
4. Is the WSDL pinned/bundled or fetched at runtime? Runtime fetch is a production outage vector.
5. Does it model DPD's error/fault responses into typed exceptions, or does it let SoapFault bubble up?
6. Are there any tests, fixtures, or recorded payloads we can use as a regression baseline?
7. Who owns the code after we take it — is there appetite to fork and maintain, or is this a reference implementation only?

Integration Approach

Stack fit PHP/Laravel, but a 2019-era package. It will fit a Laravel 5.x/6.x codebase with modest effort and a modern Laravel codebase with substantial effort (likely a fork plus constraint rewrites). ext-soap must be present in every runtime image, including queue workers and CI. It is a server-side only concern — no frontend coupling, which is clean.

Migration path Do not take a hard require on this package in the application. Recommended sequence:

1. Fork into our VCS (or vendor into app/Integrations/Dpd/) under our namespace. MIT permits this; it also transfers ownership of every future DPD API change to us.
2. Define a domain port (ParcelRegistration, LabelRetrieval, PickupScheduling, TrackingLookup) and implement it with the forked client as the adapter.
3. If a maintained alternative or DPD's current REST API is viable, the adapter boundary lets us swap it in without touching order/fulfilment code.
4. Freeze the WSDL as a bundled fixture; never resolve it over the network at request time.

If the team's appetite for owning carrier code is low, use the package purely as documentation — read the payload shapes and fault handling to write a minimal in-house client against DPD's current spec. That is often cheaper than adopting an abandoned lib.

Compatibility Audit before committing: composer why-not against the target Laravel version, PHP 8.x static analysis pass, and a check that the SOAP client doesn't rely on __soapCall magic in ways that break with typed properties. Budget for a constraint-rewrite PR plus a deprecation cleanup PR. If Laravel 10+, assume a fork is mandatory.

Sequencing

1. Spike: sandbox credentials, one label end-to-end, measure effort.
2. Adapter + domain port, with the client behind an interface.
3. Label generation → object storage → order attachment.
4. Pickup scheduling (courier call) and cut-off time logic.
5. Tracking (poll or push, whichever DPD supports for the market).
6. COD, returns, international, multi-parcel.
7. Production cutover behind a feature flag with a manual fallback path.

Operational Impact

Maintenance This is the headline cost. With no upstream releases since 2019 and zero dependents, we are the maintainers on day one. Budget: dependency/security patches, PHP/Laravel upgrade work, WSDL version updates when DPD changes contract, and fault-mapping fixes discovered in production. Realistically this is a low-to-moderate ongoing engineering line item, not a one-off integration.

Support No vendor, no community, no issue triage. Internal ownership of an on-call runbook is required. Escalation to DPD's carrier support is possible for API behaviour but not for library defects. Include DPD integration in the same support tier as payment gateways — it is revenue-path infrastructure.

Scaling SOAP calls are synchronous and per-consignment. Wrap label generation in queued jobs with retry and backoff; a batch of 500 orders must not fan out to 500 concurrent SOAP calls. Set explicit connect/read timeouts (SOAP defaults are often unbounded and will exhaust PHP-FPM workers). Expect carrier-side rate limits or throttling during peak; design a bounded worker pool per carrier. Label PDFs belong in object storage, not the database.

Failure modes

• Non-idempotent parcel creation — a timeout after DPD accepts the parcel can produce duplicate shipments and duplicate courier charges. Require a reconciliation step (query by reference before retry) and never blind-retry creation.
• SoapFault opacity — untyped faults make it hard to distinguish "invalid address" (user-fixable, don't retry) from "service unavailable" (retry). Build a fault classifier in the adapter.
• WSDL fetch failure — if fetched at runtime, this is a hard outage. Bundle it.
• Credential expiry/rotation — DPD password policies can invalidate integrations silently. Add a health check that performs a cheap authenticated call.
• Pickup cut-off drift — courier call cut-off times and holiday calendars are business rules the package will not know; own them explicitly.
• Abandoned transitive deps — a CVE in a pinned Guzzle/Symfony version with no upstream fix forces an urgent fork-and-patch.

Ramp-up For a developer comfortable with SOAP and carrier APIs: one to two days to a working sandbox label, one to two weeks to production-ready with COD, tracking, and error handling. For a developer without SOAP experience, add a few days for WSDL/XSD debugging — the tooling is far less forgiving than REST. Document the DPD payload model internally; the package's lack of docs means that knowledge otherwise lives in one person's head.