Shippingbo Laravel Package

Product Decisions This Supports

• Build vs. buy for fulfillment/shipping: whether to own carrier integrations and shipping logic in‑house, or delegate to an OMS/3PL SaaS (ShippingBo) and keep only a thin connector in our stack. This package is the artifact that makes the "buy + connect" option cheap to evaluate.
• Roadmap sequencing for order-to-ship: if ShippingBo is on the table, this informs the effort estimate for the "push orders / pull tracking & stock" epic and lets us scope an MVP (create order → get label/tracking → sync inventory) without a full RFP cycle.
• Market expansion (FR/EU): ShippingBo is a French logistics SaaS; the connector is a fast way to test whether our EU fulfillment story works with a regional OMS rather than building carrier coverage ourselves.
• Vendor strategy: whether ShippingBo becomes a strategic dependency in the fulfillment stack, a tactical option for a segment of merchants, or is rejected — the spike output feeds that call.
• Architecture direction: whether our platform exposes a stable internal ShippingBoClient boundary (recommended regardless of package choice), so a future swap to an official SDK or another OMS is a one-file change.
• Explicitly not supported: pricing, checkout UX, or any customer-facing surface. This is back-office integration plumbing; it should not drive product positioning on its own.

When to Consider This Package

Consider it when:

• The ShippingBo decision is already made or strongly favored upstream — this package informs integration cost, not vendor selection.
• We are on PHP/Laravel and willing to adopt the Splash connector framework. "Embedded" is a signal: it is a component of the Splash connector ecosystem, not a standalone SDK, so it likely pulls in Splash core abstractions and conventions.
• We need a timeboxed spike (1–3 days) to read the OpenAPI surface, understand endpoint shape, and produce a credible estimate.
• The first use case is internal/low-risk back-office sync (orders, products, stock), not a customer-facing critical path.
• We have engineering capacity to vendor/fork and own patches.

Look elsewhere when:

• ShippingBo is not chosen, or we need multi-carrier/multi-3PL abstraction — generate a client from ShippingBo's official OpenAPI spec with OpenAPI Generator, in the language of the service that will own the integration.
• We need a supported dependency: an SLA, security patches, versioned releases, or an active maintainer. Zero stars, zero dependents, and a self-hosted GitLab origin are adoption-risk signals, not quality signals — treat this as unvetted sample code.
• The consuming service is not PHP, or the integration is event-driven/webhook-first rather than CRUD sync.
• Procurement/security requires provenance, license review, or a maintained upstream before shipping to production.
• We need typed contracts and resilience (retries, idempotency, rate limits) out of the box — we will build those ourselves either way.

Default recommendation: evaluate as a reference implementation, not a production dependency.

How to Pitch It (Stakeholders)

For executives: This is a free, low-cost accelerator for answering one question — "how expensive is it to plug ShippingBo into our fulfillment flow?" It does not commit us to ShippingBo, and it should not be budgeted as a supported dependency: the project shows no adoption or maintenance signals. The ask is small: a one-to-two week spike that returns a decision-ready estimate and a working prototype, or a fast no-go. Either outcome is cheaper than discovering the integration cost mid-roadmap, and it protects the EU fulfillment timeline from an unbounded estimate.

For engineering: Treat the package as generated code we may adopt, not a library we depend on. Concretely: pin a commit SHA and vendor it into the repo; wrap it behind our own ShippingBoClient interface so the transport is swappable; assume we own auth, secrets, retries, backoff, idempotency keys, and structured logging; write contract tests against the ShippingBo sandbox and record fixtures; review the license and the generated code for anything unsafe before it touches production data. Keep the exit path open — an OpenAPI-generated client from ShippingBo's published spec is the fallback if the Splash coupling or maintenance risk proves unacceptable. Timebox the spike, and make "fork and own" an explicit, costed decision rather than a drift into dependency.