Integrations Api Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for an "integrations" surface. This package is a presentation adapter — it is the HTTP/controller layer that exposes an integrations domain (connections, providers, OAuth callbacks, sync status) as an API. It does not contain the integration logic itself. So the real decision it informs is narrow: whether the presentation layer for integrations is worth writing yourself or sourcing.
• Ecosystem lock-in assessment. With 0 stars, 0 dependents, and a single-vendor namespace (liberusoftware/module-integrations-*), the only rational framing is "are we already committed to the Liberu modular stack?" If yes, this is cheap glue. If no, it is not a candidate at all. That is a strategy decision, not a feature decision.
• Roadmap sequencing for an integrations feature. If you are on that stack, adopting this collapses a slice of work (routing, request validation, resource serialization, response shape) into a dependency, letting the team spend its budget on provider connectors and credential handling — which is where the actual product risk lives.
• Use cases it plausibly serves: a customer-facing "Connected Apps" settings screen, an internal admin view of tenant integrations, webhook/OAuth callback endpoints, and a versioned public API surface for partners to manage their own connections.
• Due diligence gating. It surfaces two concrete decisions for legal and platform: (1) NOASSERTION license means no declared license — you cannot adopt this without a legal review or a written grant from the maintainer; (2) the listed last release date (2026-10-26) post-dates today, which indicates either a future-dated tag, a timestamp parsing artifact, or an automated monorepo release pipeline. Either way, release metadata is not trustworthy enough to build a dependency policy on.

When to Consider This Package

Consider it only if all of the following hold:

• You are already running the Liberu module suite and this package's sibling modules (its domain layer, persistence, and provider clients) are in your composer.json. A presentation adapter without its domain is inert.
• You need an HTTP/API surface for integrations and are content to inherit the maintainer's route names, request/response contracts, and versioning choices.
• Your team is willing to read the source as the primary documentation — there is no visible docs site, no test-coverage signal, and no community to answer questions.
• Legal has cleared the NOASSERTION license, or you are forking it in-house and accepting maintenance ownership.
• You accept single-maintainer risk: no dependents means no downstream users stress-testing upgrades, and no ecosystem of security reports.

Look elsewhere if:

• You are building a standalone Laravel app. Use the established primitives instead: laravel/socialite for OAuth flows, saloonphp/saloon for outbound API clients, spatie/laravel-data for request/response DTOs, and hand-written controllers. That stack has hundreds of dependents and active security review.
• You need SLAs, a support contract, or a security-response process. All absent here.
• You need documented API contracts for external partners — you would be reverse-engineering them from the code.
• Your architecture is not already modular-in-packages. Adding a presentation adapter as a dependency for a layer you'd otherwise write in ~a day inverts the cost/benefit.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated liberusoftware/integrations-api, a small Laravel package that provides only the API/controller layer for an integrations feature. It has zero public adoption (0 stars, 0 dependents), no declared open-source license, and one maintainer. It is not something we should buy or depend on as a vendor. Its only legitimate use is as internal scaffolding if we were already standardised on the Liberu module stack — which we are not. Recommendation: do not adopt; revisit only if we commit to that stack, and then only as a fork we own.

To engineering (the substance): This is a presentation adapter, not an integrations engine — treat it as ~a day of routing, validation, and resource classes, not as a capability. The blockers are real, not stylistic: NOASSERTION license is a legal stop-ship; a release date in the future means the version metadata is unreliable; zero dependents means zero upgrade-path evidence. If a team member wants to borrow ideas, that is fine and free — read it, reimplement the response shaping, keep our own code. If we ever do adopt it: pin an exact version, vendor the source into our repo, add it to our dependency-review list, and assign a named owner, because no one upstream will be watching our back.