Api Bundle Laravel Package

Product Decisions This Supports

• Framework-fit decision (most important): this is a Symfony bundle, not a Laravel package. The first product decision it informs is whether the team's stack can consume it at all. For a Laravel codebase this is a "study, don't adopt" artifact; for a Symfony codebase it is at least structurally compatible.
• API layer standardization: at face value, an "API bundle" supports decisions about how you expose, version, and standardize HTTP/JSON endpoints across services. v0.14.0 sharpens this: the package also carries a SOAP service loader with per-endpoint skip controls, which tells you it is aimed at teams exposing mixed SOAP + REST surfaces from one Symfony app. That is a narrower, more legacy-flavored problem than "we need a modern API layer." If your roadmap includes an API-first initiative or consolidating inconsistent endpoint patterns, this is a candidate reference implementation for those conventions — but only the conventions, not the runtime.
• Legacy-protocol retirement decisions: the skipSoap flag is really an incremental-migration affordance — endpoint-by-endpoint opt-out of SOAP exposure while transitioning to REST. If a funded workstream is "decommission SOAP endpoints without a big-bang cutover," this is a useful pattern to borrow for how per-endpoint feature flags should be modeled in your own config schema.
• Build vs. buy vs. borrow: with 2 stars, 0 dependents, and a version history that only just reached 0.14.0 (still pre-1.0), this is not a "buy" (no vendor, no support, no SLA) and not a credible long-term "build on." The realistic decision it supports is borrow — mine it for patterns and abstractions, then reimplement in-house against your own conventions.
• Vendor-risk tolerance: it is a useful forcing function for the question "what is our minimum bar for a third-party dependency?" A single feature commit after a long quiet period is not evidence of sustained maintenance, and pre-1.0 semver means even minor bumps can break. A package with no ecosystem, no downstream users, and an irregular release cadence fails most reasonable bars for production dependencies and clarifies where your team should draw that line.
• Not a roadmap driver: nothing here should change quarterly priorities. It is a tactical, low-leverage input — relevant only if an API standardization or SOAP-retirement workstream is already funded.

When to Consider This Package

Consider it when:

• You are on Symfony and specifically want to evaluate a small, MIT-licensed bundle for conventions or scaffolding — and you genuinely have a SOAP surface to expose, filter, or wind down (the skipSoap endpoint option is the only thing in this release, and it is only meaningful if SOAP is in scope).
• You are doing pattern research — reading how another team modeled endpoint definitions, per-endpoint toggles, and service-loader filtering before designing your own.
• You are comfortable vendoring or forking the code, pinning it to an exact 0.14.x version, and owning maintenance entirely (no upstream reliance).
• The scope is internal or low-blast-radius — an admin API, an internal integration, a proof of concept — where a stale dependency is survivable.
• You have already read the source and confirmed it does something you need that is not trivially reproducible.

Look elsewhere when:

• You are on Laravel. Use the native stack instead: API Resources, Form Requests, Sanctum/Passport, and Laravel's routing/middleware — or a maintained package if you need more. The bundle/DI-container mismatch alone makes adoption costly.
• You have no SOAP endpoints. v0.14.0 adds value only to SOAP-consuming setups; for a purely JSON/REST stack this release changes nothing for you.
• The API is customer-facing, security-sensitive, or revenue-critical. Two stars, zero dependents, and a sparse pre-1.0 release history means no security response path and no community to catch regressions.
• You need LTS, SLAs, or a support contract, or you need predictable semantic-versioning stability — 0.x does not promise it.
• You need a full API platform — API Platform, OpenAPI tooling, or a mature gateway is the right comparison class, and this does not compete there.
• The alternative is writing ~200 lines yourself. For most "API bundle" scope, in-house code you control beats an unmaintained dependency.

How to Pitch It (Stakeholders)

To executives (one paragraph): We re-reviewed smartbox/api-bundle, a small MIT-licensed Symfony bundle from Smartbox Group, after its v0.14.0 release, which adds a skipSoap option letting teams exclude individual endpoints from the SOAP service loader. That is an incremental, additive change — not a maturity signal. The package still has negligible adoption (2 GitHub stars, zero dependent projects), no support channel, and remains pre-1.0, so even minor releases may break compatibility. It also targets Symfony, so it does not fit a Laravel stack without material adaptation. Recommendation: no spend, no roadmap impact. The release slightly improves the case for an engineer to spend a few hours reading it as a design reference if we greenlight API standardization or a SOAP-retirement effort; that reading is free and low-risk.

To engineering (bullets):

• Symfony bundle, MIT, published by Smartbox Group; not Laravel-compatible without rework.
• v0.14.0 change is additive only: new skipSoap option on endpoint definitions to exclude endpoints from the SOAP service loader. No deprecations, no breaking changes called out — but it is a 0.x release, so treat minor bumps as potentially breaking by default.
• Signals unchanged: 2 stars, 0 dependents, irregular release cadence. Still effectively unmaintained-by-community; one commit is not a maintenance commitment.
• The skipSoap pattern is the only thing worth borrowing — model per-endpoint protocol opt-out in our own config schema rather than importing the bundle.
• If you want it anyway: vendor it, pin the exact version, and assign an owner. Do not add it as a floating Composer dependency.
• Do not use it for anything on the critical path, in the auth path, or in a customer-facing API without an explicit risk acceptance.