Filament Openapi Docs Laravel Package

Product Decisions This Supports

• API documentation as an in-product surface, not a separate site. Because docs render inside the Filament panel, a PM can ship API reference material to internal teams, partner integrators, or support staff without standing up and maintaining a separate docs portal. This is primarily an internal enablement and support-deflection decision, not a customer-facing marketing site decision.
• Multi-version API support as a roadmap unlock. The v1.0.4 versions() in-page selector and version() dedicated pages mean a PM can commit to a versioned public/partner API strategy (v1, v2 in parallel; deprecation windows) without also committing to a bespoke docs frontend. This directly supports decisions like "can we run v1 and v2 concurrently next quarter?" and "how do we communicate breaking changes to integrators?"
• Build vs. buy: buy/adopt for docs rendering. Scramble generates the OpenAPI spec; this package renders it in the admin UI. The PM-visible scope is small and well-bounded — adopting it avoids building a docs viewer, version switcher, and sidebar navigation. The trade-off is lock-in to the Filament + Scramble pairing; if either is not already in the stack, this is a stack decision, not a docs decision.
• Multi-plugin coexistence (fixed in this release) supports multi-audience or multi-tenant panels. Separate plugin instances can now live in the same Filament panel — useful when different audiences (internal admin vs. partner portal) need different spec sets, or when a SaaS product exposes per-tenant API surfaces.
• Low-risk adoption for roadmap planning. Explicitly no breaking changes and a passing test suite (72 tests) means this can be scheduled as an incremental enhancement rather than a dedicated migration project. It does not consume meaningful engineering capacity or require a deprecation/comms plan.
• Use cases to scope work against: internal developer onboarding, partner integration hubs, support-team self-service troubleshooting, and API changelog/version-pinning experiences.

When to Consider This Package

Consider it when all or most of the following hold:

• The application already runs Filament for its admin panel and Scramble (or can adopt Scramble) for OpenAPI generation. The marginal value collapses if either is absent.
• There is a real versioned API surface — existing or firmly on the roadmap — that needs concurrent documentation. The v1.0.4 multi-version features are the strongest reason to adopt now.
• The audience is internal, partner, or authenticated — people who plausibly have Filament panel access. This is not an anonymous public docs solution.
• You want docs to track the code automatically rather than be hand-maintained; Scramble-derived specs reduce drift between implementation and documentation.
• You value low integration cost over deep customization of the docs reading experience.

Look elsewhere when:

• The docs must be publicly accessible without authentication or hosted on a marketing domain — use a dedicated docs generator/site (e.g., a static OpenAPI renderer, Redoc/Stoplight-style tooling, or a hosted docs platform).
• The team is not on Filament, or is standardizing on a different admin stack — the integration cost and coupling outweigh the benefit.
• You need authoring workflows: hand-written prose guides, tutorials, conceptual documentation, search across narrative content, or localization of long-form docs. This package renders API reference, not a docs CMS.
• You need fine-grained control over the rendered docs UI or custom interactive API consoles; verify the UI surface meets requirements before committing, since customization depth here is bounded by the plugin.
• The API is unversioned and staying that way — the headline feature of this release is then unused, and a simpler single-spec renderer may suffice.

How to Pitch It (Stakeholders)

For executives: A small, low-risk addition that lets us publish live, always-current API documentation inside the admin panel we already run. The new release adds multi-version support — so we can document v1 and v2 side by side during a migration without building or buying a separate docs platform. No breaking changes, no migration project, no new vendor contract. It reduces support load and shortens partner integration cycles, and it de-risks any roadmap item that involves shipping a new API version.

For engineering: Adopt this as the rendering layer over Scramble-generated specs inside Filament. v1.0.4 adds versions() for an in-page version selector and version() for dedicated version-specific pages, auto-discovers named Scramble APIs, and fixes the previously blocking case where multiple docs plugin instances could not coexist in the same panel. Legacy single-generator behavior is preserved, so existing integrations keep working — this is a purely additive upgrade. Test coverage is green (72 passing). Two things to validate before we commit: confirm our Scramble setup exposes named APIs cleanly, and confirm the sidebar/version UI is adequate for our audiences rather than needing customization. If the docs must ever be public and unauthenticated, this is not the right tool and we should evaluate a dedicated docs platform instead.