Api Laravel Package

Product Decisions This Supports

• Platform lock-in decision, not a package decision. netflex/api is a read-only subtree split of the API component inside netflex/framework. Adopting it is only meaningful as a consequence of adopting the Netflex platform (a commercial CMS/e-commerce SaaS). The real decision is "do we build on Netflex?" — this package is an implementation detail of that answer.
• Integration and storefront work on Netflex. If the roadmap includes custom storefronts, integrations, or internal tooling against a Netflex backend, this component is the layer your code will sit on top of. It informs estimates for "how much glue code do we write ourselves?"
• Build vs. buy framing. This is firmly "buy" — you get it as part of the platform. There is no build alternative worth evaluating; the alternative is choosing a different platform entirely (Shopify, CommerceTools, custom Laravel + headless CMS).
• Explicitly rules out general Laravel API work. Despite the name, this is not a general-purpose HTTP client, API toolkit, or Saloon/Laravel-HTTP-client replacement. Any roadmap item that reads "use this for our REST integrations" is a misread of the package and should be redirected.
• Dependency hygiene / architecture review signal. Because it is a split (not a standalone product), the correct dependency in your own composer.json is almost always netflex/framework, not this package. Roadmap and architecture reviews should treat direct dependence on the split as a smell unless there is a concrete reason.

When to Consider This Package

Consider it when:

• You are already committed to Netflex and need the API layer in isolation — e.g., a small internal package that must not pull the entire netflex/framework.
• You are debugging, extending, or reading the Netflex SDK to understand how requests are shaped against Netflex endpoints.
• You are contributing upstream (and even then, PRs belong in the netflex/framework monorepo, not here).

Look elsewhere when:

• You need a documented, community-supported, independently versioned package. Zero stars, zero dependents, and a "[READ ONLY]" banner mean no external validation, no issue tracker of its own, and no SemVer promises you can rely on.
• You need a general Laravel API client. Use Laravel's built-in HTTP client or a package like Saloon.
• You need anything not tied to Netflex's proprietary endpoints — this package is meaningless without that backend.
• You need to fork or patch. Any local changes will be blown away by the next subtree split; forking is a maintenance trap.

How to Pitch It (Stakeholders)

To executives (one line): This is plumbing inside a commercial CMS platform, not a product we are betting on. It carries no adoption risk by itself and no value outside Netflex — so the only question worth their time is whether we are standardizing on Netflex.

To engineering leadership: Treat netflex/api as an internal artifact of netflex/framework. Do not add it as a direct dependency without a specific reason; the full framework is the supported entry point. Do not fork it — the subtree split will overwrite local changes, and upstream fixes must go to the monorepo.

To the delivery team: Its practical significance is scoping. If we are on Netflex, this is the layer we extend and debug, and we should budget time to read its source because public documentation is thin. If we are not on Netflex, remove it from consideration entirely — the name is misleading and it will otherwise get proposed for unrelated API integration work.

Risk summary: Low blast radius, low strategic weight. The real risks are platform-level (vendor dependency, small ecosystem, thin community signal around the Netflex SDK) rather than package-level.