Shippingbo Laravel Package

Technical Evaluation

Architecture fit. splash/shippingbo is an OpenAPI connector for ShippingBo, a French e-commerce OMS/WMS (order orchestration, stock, picking/packing, carrier labels). The artifact is almost certainly a thin, largely generated client — an HTTP transport plus DTOs mapping to ShippingBo's REST surface — not a domain-rich Laravel package. It fits only one narrow architecture slot: an outbound adapter in the inventory/fulfilment bounded context, sitting behind your own port interface. It should never be allowed to leak ShippingBo DTOs into application or domain code. If ShippingBo is not already your OMS/WMS of record, this package has no reason to enter the dependency graph.

Integration feasibility. Distributable via Composer from a GitLab VCS repository, which implies an auth token (gitlab-token in auth.json or CI-scoped credentials) on every developer machine and every build agent — an immediate CI/CD and secret-management obligation. There is no meaningful metadata: zero stars, zero dependents, score 0, no visible version constraints for PHP or Laravel/Illuminate. Expect to pin a commit SHA rather than a semver range. Feasibility is therefore "technically possible, procedurally awkward": the first hour of work is authentication plumbing, not integration.

Technical risk. High, and concentrated in provenance rather than code quality:

• Abandonment / bus factor. Zero adoption signals and a single GitLab namespace ("splash-connectors") indicate an agency-published connector, likely maintained per-client engagement. No evidence of a release cadence, changelog, or deprecation policy.
• Generated-code drift. OpenAPI-generated clients track a spec snapshot. When ShippingBo changes a field or endpoint, the package does not fail loudly — it fails at deserialization time in production.
• No security posture. No documented disclosure channel, no CVE history, no dependency-audit visibility. composer audit will tell you about transitive packages but not about this one's handling of bearer tokens, retries, or PII in logs.
• Licensing ambiguity. The license file must be read before legal review; "bundle" naming hints at Symfony conventions, so Laravel service-provider auto-discovery may not exist at all.

Key questions for the vendor/maintainer. Who owns this repository and under what SLA? Which ShippingBo API version and OpenAPI spec commit is it generated from? What is the authentication model (API key, OAuth client credentials, per-tenant tokens)? Are rate limits and 429/Retry-After handled, and is retry idempotent? Does it cover webhooks/subscriptions, or is polling the only option? What are the tested PHP and Laravel version ranges? Is there a tagged release compatible with our framework version, and what is the license? Is there an official ShippingBo SDK we should prefer instead?

Integration Approach

Stack fit. Assume PSR-18/PSR-7 HTTP underneath, likely Guzzle, with a hand-written or generated client class. That is framework-agnostic and will run inside Laravel, but it is not a Laravel package in the idiomatic sense — do not expect config publishing, facades, queue integration, or Eloquent models. Treat it as a vendor SDK you happen to install with Composer.

Migration path. Do not integrate the package directly into controllers, jobs, or models. Define an internal port (ShipmentGateway, StockReader, OrderSubmitter) in your own namespace, implement it with an adapter that wraps splash/shippingbo, and bind it in a service provider. Everything downstream — sync jobs, webhook handlers, admin screens — depends only on the port. This makes the exit path a one-class swap to raw HTTP or an alternative SDK, which matters enormously given the adoption risk. Persist raw request/response payloads for a bounded retention window to support replay and reconciliation.

Compatibility. Pin the dependency to an exact commit or tag and mirror the repository into your own GitLab/GitHub organisation (vendor fork). Mirrored forks let you patch, audit, and survive upstream disappearance without touching every consumer's composer.json. Lock PHP and Laravel constraints in your root composer.json and add the package to your dependency-review allowlist.

Sequencing.

1. Timeboxed spike (1–2 days). Fork, install, authenticate against a ShippingBo sandbox tenant, and exercise the four or five endpoints you actually need. Confirm the client's DTOs match current live responses — this alone often kills the package.
2. Contract test harness. Record real sandbox responses as fixtures; assert the client deserializes them. This is your early-warning system for spec drift.
3. Adapter and port. Implement the internal interface; keep the vendor types confined to the adapter package.
4. Single-channel canary. Enable for one sales channel or one warehouse, with order creation behind an idempotency key and a reconciliation job.
5. Broaden. Expand to all channels only after a full order-to-shipment cycle has run clean for a defined window.

Operational Impact

Maintenance. Budget for owning the fork. Realistically this is 2–4 hours per quarter of dependency review plus whatever ShippingBo API changes force. The absence of upstream semver means upgrades are manual diffs, not composer update. Assign a named owner; unowned generated connectors rot silently.

Support. GitLab issues on a low-traffic namespace are effectively best-effort or nonexistent. Your real support channel is ShippingBo's own API documentation and their account manager. Negotiate API access and a technical contact as part of the commercial relationship — that is worth more than the package.

Scaling. Scaling is bounded by ShippingBo's API rate limits, not by this package. Expect to run all syncs through queued jobs with per-tenant concurrency caps, exponential backoff with jitter on 429/5xx, and circuit breaking on repeated failures. Polling-based stock sync will dominate your job throughput; webhooks, if available, are strongly preferable and should be verified by signature and deduplicated by event ID.

Failure modes.

• Token expiry or rotation causing silent 401s across all sync jobs — needs alerting on auth failures specifically.
• Schema drift causing deserialization exceptions on new fields — mitigate with lenient parsing and dead-letter queues.
• Duplicate order submission on retry without idempotency keys — a customer-visible, financially material failure.
• Stock oversell during partition or rate-limit windows — reconcile against a periodic full snapshot rather than trusting incremental events alone.
• Webhook loss or out-of-order delivery — treat webhooks as hints, poll as the source of truth.
• Vendor disappearance — mitigated by the mirror and the port abstraction, but only if both are actually implemented.

Ramp-up. The package itself is small; a mid-level Laravel developer can read it in an afternoon. The real ramp-up is ShippingBo domain literacy — the order lifecycle states, allocation rules, carrier and label semantics, and returns flow — which is days, not hours, and is not documented by this repository. Plan for one developer to spend a week on spike plus contract harness before committing, and treat a zero-adoption, zero-star dependency as a build-versus-buy decision in its own right: writing a focused 400-line HTTP client against the endpoints you need may be cheaper, safer, and more maintainable than adopting an unmaintained generated wrapper.