Staci Laravel Package

Product Decisions This Supports

• 3PL / fulfillment integration feasibility. Whether we can connect our order pipeline to STACI (appears to be a logistics/fulfillment provider; the "Embedded" qualifier suggests an embedded-fulfillment variant) for order intake, stock/inventory sync, shipment confirmation and tracking, and returns — and how much of that this connector actually covers versus what we'd still build.
• Build vs. buy vs. integrate. A concrete data point in the "custom integration vs. off-the-shelf connector" decision. If we are already on the Splash connector framework, the marginal cost of adding STACI is measured in days, not engineering weeks. If we are not on Splash, this package is not the cheap option it appears to be — it drags in a framework decision.
• Connector-layer architecture / platform standardization. Choosing Splash as our integration layer is a multi-year commitment. This package is evidence for or against that bet: it tells us whether the ecosystem actually covers the vendors our roadmap needs, and whether those connectors are maintained.
• Roadmap sequencing and market expansion. Expansion into geographies or channels served by STACI is gated on integration effort. A cheap, working connector can pull a launch forward by a quarter; an unmaintained one can silently delay it.
• 3PL vendor selection (RFP input). "Does our existing stack already have a connector for you?" is a legitimate scoring criterion when shortlisting fulfillment partners. It reframes the 3PL conversation from price-per-pick to total integration cost.
• Embedded-commerce / platform use cases. If "Embedded" means fulfillment embedded inside a merchant or marketplace platform, this connector is the plumbing behind a "fulfillment as a feature" offering — relevant if we resell or white-label logistics.
• Risk register entry. Zero stars, zero dependents, no visible release cadence. That is a supply-chain risk for a production dependency, and it should be tracked as such rather than discovered during a peak-season incident.

When to Consider This Package

Consider it when:

• STACI is a committed commercial partner — contract signed or in final negotiation. Not "we might use them."
• We are already running Splash for other carriers or 3PLs. In that case this is a small adapter that reuses our existing auth, queueing, logging, and error handling, and the real cost is a spike, not a project.
• We need a reference implementation of STACI's API/EDI contract — endpoint shapes, payload schemas, auth flow, retry semantics — far more than we need a supported library. Even a rough connector compresses discovery.
• We have PHP engineering capacity to fork and own the code. Assume from day one that we are the maintainer.
• The scope we need is narrow and stable: push orders, pull stock, pull shipment/tracking. Simple, well-bounded message flows.

Look elsewhere when:

• We are not on Splash. Note the repository is named staci-bundle — this reads as a Symfony bundle, not a Laravel package. Under a Laravel codebase expect friction: service-provider wiring, container/DI assumptions, config conventions. Budget for that or pick a Laravel-native route.
• We need a supported dependency. 0 stars and 0 dependents means no community, no third-party bug reports, no security review, no Stack Overflow answers, no upgrade path. Verify tagged releases, last-commit date, and maintainer responsiveness before writing a line of production code. If any of those are thin, this is a sample, not a library.
• Volume or complexity is high. Multi-warehouse allocation, dropship, customs documentation, partial shipments, and reconciliation flows generally exceed what a thin connector covers and justify a dedicated middleware layer or direct integration against STACI's official API/EDI spec.
• We need SLAs, uptime guarantees, or audit compliance. Open-source connectors carry no vendor SLA. If fulfillment downtime is revenue-critical, the integration needs a contract behind it, not a Git repository.
• STACI publishes an official SDK or a well-documented REST API. An official client with a support channel usually beats an unmaintained third-party adapter, even at higher sticker price.
• We are not a PHP shop, or PHP is a legacy corner of the stack. Do not let a free connector dictate language choice for a revenue-critical path.

How to Pitch It (Stakeholders)

For executives — one paragraph: We have an opportunity to connect our order system to STACI, a fulfillment partner, using an existing open-source connector instead of building the integration from scratch. A custom 3PL integration typically costs several engineering weeks plus ongoing maintenance; this connector could reduce the first working version to a short, timeboxed spike. The caveat is maturity: the package has no meaningful adoption — no stars, no dependent projects, no visible community — so we should treat it as a head start, not a finished product, and plan to own the code. Recommendation: approve a one-sprint, one-engineer evaluation, gated on the STACI commercial agreement, with a go/no-go on production use only after we confirm it covers order, stock, and shipment flows and that we can maintain a fork. This caps our downside at roughly a week of engineering while preserving the option to save a month.

For engineering — the substance: Thin adapter, small surface area, low conceptual complexity — the risk is entirely in maintenance and fit, not in the code being hard. Vendor it into our repo rather than depending on it via Composer, put it behind our own FulfillmentProvider interface so STACI is swappable, and add contract tests against recorded payloads. Expect Symfony-style bundle conventions even though our stack is Laravel; do not fight that, just wrap it. Hard requirements before production: confirmed auth and token refresh, idempotency on order submission, retry/backoff on 5xx, dead-letter handling for malformed payloads, and observability hooks (structured logs, metrics on sync lag and failure rate).

For product — the decision we are actually making: The connector is cheap; the commitment it implies is not. Adopting it nudges us toward Splash as our long-term integration layer and toward STACI as a long-term fulfillment dependency. Make those two platform decisions explicitly and separately, and use the spike as evidence for them — not as a way to avoid making them.