Nova Api Laravel Package

Product Decisions This Supports

• Build vs. buy for an admin-adjacent API. If Laravel Nova is already the operational source of truth, this package converts "stand up a REST layer for our back-office entities" from a bespoke controller/auth/serialization project into a configuration and hardening task. The buy case is strongest when the exposed entities are the ones staff already manage in Nova.
• Roadmap sequencing for "open the back office" initiatives. Partner portals, internal service integrations, mobile ops apps, and lightweight reporting feeds can be scoped as per-resource exposure flags rather than net-new services — a smaller estimate, a shorter path to first external release, and one permission model to maintain instead of two.
• Feature scope: actions as a product surface. The v1.3.0 bump to opscale-co/actions ^4.0 signals the architecture is built around exposing Nova actions, not just CRUD. That supports decisions like "let a partner trigger an approval or reconciliation workflow from their own system" without commissioning a workflow API — but it also means action semantics become part of your external contract, so scope those deliberately.
• Platform consolidation / surface-area reduction. Fewer bespoke controllers, token shims, and duplicated validation rules to secure, document, and version. The trade-off is concentration risk: the external surface's shape is now coupled to an admin UI's field definitions.
• Use cases to validate first: read access to Nova resources for a named partner or internal client; programmatic invocation of existing Nova actions; admin-adjacent reporting extracts. Poor fits: high-volume public APIs, anything needing a contract you intend to version independently of the admin panel, latency-sensitive consumer traffic, or streaming/webhook-heavy integrations.
• A decision this package should not be used to make: it is not evidence that you should adopt Nova. The value is entirely levered to Nova already being in place; if Nova is being evaluated or retired, this package is not a factor in that call.

When to Consider This Package

Adopt when most of these hold:

• Laravel Nova is deployed and is the system of record for the entities you want to expose.
• The consumer set is small, known, and credentialed — partners, internal services, ops tooling — not anonymous public traffic.
• You want Nova's policies, filters, and action definitions to be the API's authorization contract, so permissions are maintained in one place.
• Your team is PHP/Laravel-fluent and values low operational overhead over a standalone service with its own deployment, schema, and auth model.
• Traffic is read-mostly or action-triggering; you are not chasing sub-100ms p99 or extreme throughput.
• You accept the response shape being derived from Nova field definitions and are willing to verify how much payload shaping you get before it becomes someone else's contract.

Look elsewhere when:

• The API is a product in its own right — external developer audience, published versioning guarantees, SDK obligations. You want a contract you own, not one inherited from an admin UI.
• Nova is not in the stack or is being retired.
• You need streaming, GraphQL, high-volume webhooks, or fine-grained rate limiting that a Nova-derived surface won't naturally express.
• Maturity and bus-factor risk is unacceptable for your request path. The project shows 0 stars and 0 dependents — effectively no external validation, no community fallback, and no signal that anyone else is running it in production. For a package sitting in front of partner-facing data, plan for the possibility that you are the maintainer of last resort: fork it, or budget for replacing it.
• Release discipline doesn't meet your bar. v1.3.0 is a single-line dependency major bump (opscale-co/actions to ^4.0) with no behavioral notes, migration steps, or compatibility matrix. A transitive major landing as a "feature" tells you to pin versions, read upstream changelogs yourself, and run a regression pass on every bump rather than trusting semver. If your team can't absorb that overhead, choose something with a livelier maintenance trail — or build the thin layer yourself; the scope here is genuinely small.

Recommended gate before adoption: a time-boxed spike covering auth fit with your existing token/SSO setup, how much payload shaping you actually get versus accepting Nova's defaults, and whether action invocation meets audit-logging requirements. Treat a clean spike as approval for a bounded integration, not for a long-lived platform commitment.

How to Pitch It (Stakeholders)

For executives (one paragraph): We already run Laravel Nova as our back-office system. This package turns that investment into an integration surface — the same resources, permissions, and approval workflows our staff use become callable by partners and internal tools. It converts a "build a new API service" line item into a configuration and hardening task: weeks rather than quarters to a first external release, and one permission model to audit instead of two. The trade-off is that the external API inherits its shape from an admin panel, so it suits a small, known set of credentialed consumers — not a public developer platform. It's also a young, unproven open-source project with no adoption we can point to, so the recommendation is to adopt it as a thin, replaceable layer with a spike and a fallback plan, not as a strategic platform bet.

For engineering: The package exposes Nova resources and actions over HTTP, so authorization stays where it already lives (Nova policies) and we avoid duplicate controller and validation code. It depends on opscale-co/actions; v1.3.0 moves that to ^4.0 with no behavioral notes, so the ask is to pin the dependency, read the upstream changelog, and run a regression pass over action endpoints before we bump — routine, but not free. Prior art is thin: zero stars, zero dependents, so assume no community support and keep the integration narrow enough to fork or rip out. Before committing, spike three things: auth model fit with our existing token/SSO setup, how much we can shape response payloads versus accepting Nova's defaults, and whether the action-invocation surface satisfies our audit-logging requirements. If payload shaping turns out to be inflexible, we want to know that before it becomes the contract our partners code against. If the spike is clean, this is a small, well-bounded integration; if not, the same scope is a few weeks of hand-written Laravel.