Laravel Shiprocket Api Laravel Package

Product Decisions This Supports

• Shipping/logistics integration scoping (India): This package wraps the Shiprocket REST API for Laravel, so it is directly relevant to decisions about how we fulfil orders, surface courier rates, generate AWB/labels, and expose tracking. Choosing it (or not) is a build-vs-buy decision on our shipping integration layer.
• Build vs. buy: A maintained wrapper removes the need for us to write and own auth/token handling, request signing, and endpoint plumbing against Shiprocket. The trade-off is that our integration roadmap becomes coupled to a third party's release cadence and API coverage.
• Platform upgrade sequencing: v2.0.0 is a breaking release — it requires PHP 8.x and drops support for the PHP 7.x line that 1.0.4 served. This is now an input to our Laravel/PHP upgrade roadmap: any service still on PHP 7.4 must stay pinned to 1.0.4 or be upgraded before adopting v2.
• Risk register / dependency posture: The release removes Psalm static analysis. That is not a feature change, but it is a quality-signal change worth logging when we assess how much we trust this dependency in a revenue-path flow (order fulfilment).
• Buy-vs-wrap-vs-fork: Because the package is a thin wrapper on a documented REST API, forking or writing a small internal client remains a credible alternative if coverage gaps or maintenance risk become material.

When to Consider This Package

Consider it when:

• We are building or maintaining a Laravel application on PHP 8.x that sells into India and uses Shiprocket as the shipping/fulfilment aggregator.
• We need standard shipping primitives — courier/serviceability checks, rate calculation, order/shipment creation, pickup, label/manifest generation, and tracking — and want them as framework-native (facade/config/service provider) calls rather than bespoke HTTP glue.
• We want to ship quickly and accept a third-party wrapper in exchange for less code to own.
• Our platform is already on, or is about to be on, PHP 8.x (mandatory for v2.0.0).

Look elsewhere or proceed with caution when:

• We are on PHP 7.x — stay on 1.0.4, or better, treat the PHP 8 upgrade as the prerequisite work.
• Our integration needs are non-standard or deep — multi-warehouse routing, NDR workflows, COD remittance reconciliation, webhook handling, bulk operations. Validate endpoint coverage first; a wrapper typically lags the upstream API.
• Maintenance risk is unacceptable. This is a small, effectively single-maintainer package (@seshac) with a low release cadence. For a payment-adjacent, revenue-critical fulfilment path, budget for the possibility of vendoring or forking.
• We need vendor-backed SLAs or support — there is none implied here; this is community software wrapping a commercial API.
• We are not on Laravel at all, or are on a Laravel version this package does not target — verify the supported Laravel range in composer.json before committing.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating an open-source Laravel package that connects our storefront to Shiprocket, the shipping aggregator we would use for Indian fulfilment. It gives us courier selection, rate quotes, label generation and tracking without us building that plumbing from scratch — a clear time-to-market win and less code for our team to maintain. The main caveats are dependency risk (a small, single-maintainer project) and a hard requirement that our platform run PHP 8; the newly released v2.0.0 enforces that. Recommendation is to adopt it for standard shipping flows after a short proof-of-concept against our real order volume, while keeping an internal fallback path in mind.

For engineering (the short version):

• What it is: A thin Laravel wrapper around the Shiprocket REST API — config, service provider, facade, and endpoint helpers. Not a reimplementation; capability is bounded by Shiprocket's own API.
• What v2.0.0 actually changes: PHP 8.x support (the headline and the breaking change), PHP-CS-Fixer bump, and Psalm removal. There are no new product features in this release — treat it as a compatibility/tooling release that gates PHP 7 users to 1.0.4.
• Action items before adoption: confirm our PHP and Laravel version fit the package's composer.json constraints; gap-check the endpoints we actually need (rates, shipment creation, pickup, label/manifest, tracking, cancellations, returns/NDR); spike a sandbox integration against Shiprocket test credentials; confirm how credentials and webhook secrets are configured and whether tokens are cached/refreshed sensibly.
• Risk to note in the ADR: single-maintainer project, no Psalm static analysis in v2, and a wrapper that will always trail upstream Shiprocket API changes. Mitigation: encapsulate all usage behind our own ShippingGateway interface so the package is replaceable with a direct REST client or a fork without touching domain code.