Nova Api Laravel Package

Product Decisions This Supports

• Vendor integration scoping and estimation. The library is a working map of the NOVA API surface — endpoints, auth flow, request/response shapes, error handling. Before committing roadmap capacity to a NOVA integration, a spike against this client gives a far more credible estimate than reading vendor docs, and it surfaces which capabilities are actually reachable today versus which need a vendor ask.
• Build vs. buy for the integration layer. This is the "buy" option priced at zero (MIT). The PM decision is not "adopt or not" but "fork, wrap, or replace": read the source, decide whether to vendor the code as a starter, keep it as an isolated adapter behind our own interface, or hand-roll a thin Http:: client. Because the package is archived, fork-and-own is the realistic path — which makes this a resourcing decision, not a dependency decision.
• Roadmap sequencing and dependency risk. Archived status, 1 star, and 0 dependents are the relevant data points: no maintainer, no community validation, no bus factor. If NOVA sits on the critical path, this package is evidence that we will own the integration code, and that ownership belongs in the plan and the budget rather than being discovered mid-sprint.
• Enabling low-stakes use cases cheaply. Internal admin tooling, one-off data migrations/backfills, batch reconciliation jobs, and prototype/spike work — cases where time-to-first-call beats long-term support and a scrappy path is the right call. Approving its use here is a clear, bounded yes.
• Documentation surrogate. Where NOVA's vendor docs are thin, the client's method signatures and DTOs function as the de facto API contract — useful for spec reviews and for writing acceptance criteria.
• Security and maintenance review input. Any adoption triggers a dependency-review decision (pin, vendor, or wrap) that should be made explicitly and recorded, not defaulted.

When to Consider This Package

Consider it when:

• You already have, or are actively evaluating, a NOVA API account or partnership — otherwise it is irrelevant and should not enter the dependency graph.
• The integration is low blast-radius: internal tool, batch job, migration script, or a time-boxed spike where the goal is to learn the API fast.
• You intend to fork it under MIT and own the code, with a named owner and a plan to keep it current against PHP and Laravel majors.
• You want a cheap way to enumerate the API's real capabilities to firm up a build estimate or a vendor conversation.

Look elsewhere when:

• The integration is customer-facing or on the critical path with an SLA. An archived package with zero dependents and a single star is a maintenance liability, not a foundation.
• You need active maintenance, security patches, or forward compatibility — Laravel ships majors annually, and an archived client will silently drift out of compatibility.
• The client is a thin HTTP wrapper without a service provider, facade, typed DTOs, retries, or rate-limit backoff. At that point the dependency costs more to audit than a ~100-line in-house client costs to write.
• You need webhooks, event handling, idempotency, or observability hooks — verify coverage first; assume you will build these yourself.
• Your stack isn't Laravel/PHP, or the API version you need postdates the last tagged release.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed client for a vendor we're evaluating. It costs nothing to trial and can compress the discovery phase of a NOVA integration from weeks to days — that's the value. It is not a supported product: it is archived, has effectively no user base, and has no maintainer, so it cannot sit under anything customer-facing without us owning the code. The ask is small and reversible: a time-boxed spike to de-risk the estimate, then an explicit fork-or-build call. Framing it this way keeps the decision about our ownership cost, not about adopting a third-party dependency.

To engineering: Treat it as a spec, not a dependency. Read the source — it's small enough to review in an afternoon — and use it to confirm auth, pagination, and error semantics. If we proceed, we vendor or fork it, pin the version, and hide it behind our own NovaClient contract so swapping in a hand-rolled Http:: implementation is a one-file change. We own retries, backoff, logging, and tests regardless. Recommendation: allow it for internal and prototype work now; require a fork-with-owner before it touches anything in the product path.