enan/pathao-courier
A Laravel wrapper for Pathao Courier that simplifies integrating delivery services into your app, with support for creating orders, calculating delivery charges, tracking parcels, and managing courier statuses via a clean, configurable API.
Architecture fit. The package is a conventional Laravel integration wrapper: service provider, publishable config, facade/DI binding, and an HTTP client layer over Pathao Courier's merchant REST API (auth, price quote, order create, tracking, store and city/zone/area lookups). It is a good fit only if the consuming application is itself Laravel and the business operates in, or ships to, Bangladesh. It should sit behind an app-owned CourierGateway interface rather than being called directly from controllers or models — the facade is convenient but couples domain code to a 14-star third-party dependency. For polyglot estates or non-Laravel services, the value proposition collapses; the same work is a thin Guzzle client.
Integration feasibility. High for a spike, moderate for production. Composer install, publish config, inject PATHAO_* credentials, and a Laravel developer can produce a price quote and an order in a day or two against sandbox. Production readiness depends on unverified questions: whether token acquisition/refresh is cached and handled on 401, whether the full endpoint surface (bulk orders, returns, order info, store listing, address hierarchy) is covered, and whether any tests run against Pathao's sandbox versus only faking HTTP. The "opportunity: 10.66" signal is the real argument here — the Bangladesh courier-package niche is underserved, so a young package with 14 stars is early rather than discredited.
Technical risk. Concentrated in three areas. (1) Supply risk: single maintainer, zero dependents, no downstream validation — bus factor of one on a critical order path. (2) Contract risk: no evidence of versioned coverage of Pathao's API, idempotency handling, or rate-limit/backoff semantics; a courier API change breaks fulfillment silently. (3) Correctness risk: logistics integrations fail on business-level errors returned inside HTTP 200, on address-hierarchy drift (city/zone/area IDs), and on duplicate order creation during retries. A January 2026 release is a positive freshness signal but not proof of cadence.
Key questions for the maintainer/ spike.
composer.json constraints (Laravel 10/11/12, PHP 8.1+/8.2+), and is there a test suite using Http::fake plus any sandbox tests?Stack fit. Laravel 10–12, PHP 8.1+, Composer, queue workers, and the framework HTTP client. Natural home is a modular monolith or Laravel commerce/OMS backend serving the Bangladesh market, paired with Horizon (or equivalent) for queued dispatch and a shipments table storing Pathao IDs, statuses, and raw request/response payloads for audit and replay.
Migration path. Treat the package as an implementation detail from day one. Define an internal port (CourierGateway with quote, createShipment, cancel, track, listCities) plus DTOs and a domain error enum; bind the package's client as one adapter. Persist Pathao identifiers and a local status machine. This costs roughly half a sprint and buys the option to swap in a hand-rolled client or a second courier without touching order logic.
Compatibility. Verify composer.json constraints against the host app's Laravel/PHP versions and Illuminate HTTP/Guzzle pins before committing; check that config keys are namespaced and that the package publishes no migrations or assets that collide. Confirm the facade alias does not conflict with existing bindings, and confirm the package does not pin transitive dependencies that block framework upgrades.
Sequencing.
Maintenance. Plan to own it. Pin an exact version, watch upstream releases, and budget 1–2 days per quarter for compatibility patches and Pathao API changes. If order creation is revenue-critical, fork into a private VCS early and cherry-pick upstream; the MIT license permits this, and the cost of forking later under incident pressure is far higher.
Support. No commercial backing and no meaningful community to escalate to. The team becomes first-line support, so a written runbook is mandatory: how to rotate credentials, how to requeue a failed shipment, how to reconcile a status mismatch, how to contact Pathao merchant support with the right identifiers.
Scaling. The package is I/O-bound, not CPU-bound; throughput is capped by Pathao's per-merchant rate limits and account tier, not by PHP. Scale with queue workers, bounded concurrency, and backoff — not parallel per-order fan-out. Bulk operations should be batched to control memory and to keep partial-failure reporting tractable. The package itself introduces no caching or connection pooling, so plan for that at the adapter layer.
Failure modes to instrument. Token expiry mid-batch; duplicate orders from retried jobs without idempotency; 5xx and timeouts not mapped to retryable exceptions; business errors inside 200 responses treated as success; stale city/zone/area IDs rejecting otherwise-valid addresses; local-vs-courier status desync when webhooks are dropped (requires a scheduled reconciliation job); silent no-ops when config is missing.
Ramp-up. A Laravel developer is productive on basic calls in under a day. Understanding Pathao's address hierarchy, order state machine, pricing rules, and return workflow takes another 2–3 days — that domain knowledge, not the package, is the real onboarding cost. Add one day for ops/monitoring ownership. Given zero dependents and 14 stars, assume no tribal knowledge exists in the organization and document everything the spike teaches.
How can I help you explore Laravel packages today?