Kit Laravel Package

Product Decisions This Supports

• Build vs. buy (really: fork vs. invent) for API foundations. Kit is a starter kit you clone, not a Composer package you install. The strategic decision it informs is whether to adopt a proven, opinionated substrate — versioned routes, RFC 9457 problem details, cursor pagination, token abilities, deprecation/sunset policy, signed webhooks — or spend a quarter re-litigating those conventions in design review for every new service. Forking Kit makes "our API standards" an artifact you own rather than a recurring debate.

• Time-to-first-contract for a new API product. php artisan make:endpoint emits the full six-piece vertical slice — route, Form Request, payload, invokable controller, resource, Pest test — and CI refuses to pass while generated TODOs remain. This converts "weeks to a documented, standards-compliant first endpoint" into days, and removes the per-team argument about where validation, casting, and error shaping live.

• Whether to promise API stability to external consumers. #[Deprecation] / #[Sunset] with an automatic 410 after the sunset date, conditional requests (ETag/304), lost-update preconditions (412/428), and idempotency keys are the actual mechanics behind a published compatibility policy. This is a roadmap and contract commitment — decide it before signing a partner agreement, not after.

• Partner and enterprise integration readiness. Contract-tested OpenAPI (spec and real responses validated together), least-privilege token abilities, machine API keys with hard expiry caps, security audit logging with hashed emails, and ProductionSecurityChecks that refuses to boot without HTTPS, an https:// APP_URL, APP_DEBUG=false, explicit CORS origins, and trusted hosts. That is a defensible answer in a vendor security questionnaire and materially shortens procurement review.

• Webhook / event strategy. CloudEvents-shaped, signed, queued-after-commit deliveries with backoff, Retry-After handling, auto-disable on repeated failure, and per-delivery audit records turn "we'll notify customers when things change" from a research spike into a scoped, schedulable feature with a fixed pipeline to estimate against.

• Localization scope. Accept-Language support plus a test enforcing key parity across lang/en/api.php and lang/es/api.php gives a concrete answer to "can we ship Spanish-language API responses?" — one sprint of translation work, not an unbounded content-ops commitment. Worth deciding early if LATAM or EU markets are on the roadmap.

• Team topology and onboarding cost. PHPStan level 10, Rector, Pint (PER preset), Pest, and a legible OpenAPI readiness gate — all enforced in CI alongside a production image build and boot — plus an AGENTS.md written for coding agents and their supervisors, make this a credible substrate for AI-assisted delivery with a real quality floor. The tradeoff is a steeper day-one ramp; budget for it.

• Ownership and support risk as an explicit input. 115 stars, zero dependents, a solo maintainer, and a low opportunity score. The correct framing in any decision doc is an accelerator you fork and own, not a vendor dependency. Pin Laravel, api-toolbox, Scribe, and legible; treat Laravel major upgrades as a deliberate project. The five-gate CI becomes your real safety net, so treat it as a first-class deliverable, not scaffolding.

When to Consider This Package

Adopt when:

• You are starting a new greenfield Laravel API and expect to expose it to external consumers, partners, or multiple internal clients where HTTP semantics matter.
• You have (or want) published API standards — versioning, error shape, pagination, deprecation — and no appetite to author them from scratch.
• You need enterprise/procurement readiness early: security questionnaires, token scopes, audit logging, HTTPS/CORS hardening defaults.
• Your team is comfortable with an opinionated, strict toolchain (PHPStan level 10, Rector, Pint, Pest) and will accept "the gate is red, the change isn't done."
• You are experimenting with AI-assisted delivery and want a codebase with machine-readable conventions and an AGENTS.md contract.
• Webhooks or partner eventing is on the near-term roadmap — the delivery pipeline is the hardest thing to retrofit.

Look elsewhere when:

• You are adding to an existing Laravel app. Kit is a fork-and-live-inside template; retrofitting it means migrating routes, error handling, and CI wholesale. Cheaper to cherry-pick api-toolbox and Scribe directly.
• You need a JSON:API or GraphQL contract — JSON:API was deliberately removed; this is plain JsonResource with a specific shape.
• You need vendor-backed support, SLAs, or a predictable upgrade path. Solo maintainer, no dependents; you are the maintainer once you fork.
• Your team is small and velocity-first and would treat the five gates as friction rather than insurance. The strictness is the value; if you'll disable it, you're paying the cost without the benefit.
• The API is internal-only, short-lived, or a prototype — Laravel + Sanctum alone is faster to a first demo.
• You need cookie/session SPA auth as the primary model. Kit is token-first with sanctum.expiration deliberately off for long-lived API keys.

How to Pitch It (Stakeholders)

To executives: Kit is a proven starting point for new APIs that bakes in the things enterprise buyers and security reviewers ask about — versioned endpoints, standard error responses, scoped API keys with expiry caps, audit logging, signed webhooks, and enforced HTTPS/CORS in production. It compresses "first documented, standards-compliant endpoint" from weeks to days and gives us a defensible answer in procurement. The honest caveat: it's a solo-maintained open-source project with a small community, so we adopt it by forking and owning it, with pinned dependency versions and a five-gate CI pipeline as our safety net. That's a modest, bounded maintenance commitment — not a vendor bet.

To engineering: This is a Laravel 13 starter kit you clone, not a package you install. It arrives with Sanctum token auth, versioned routes under routes/api/v1.php, RFC 9457 problem details and the rest of the HTTP standards via api-toolbox, Scribe-generated OpenAPI validated by contract tests, a dependency review gate, and PHPStan level 10 / Rector / Pint / Pest wired into CI along with a production image build and boot. The workflow is generator-first: make:endpoint writes the six pieces of an endpoint and CI fails until you finish the TODOs and regenerate the spec. Read AGENTS.md first, then docs/README.md, then one controller. Expect a real ramp — the gate is strict and the fix order (Rector, then Pint, then PHPStan, then tests) matters — but the payoff is that nobody re-decides HTTP semantics per endpoint, and quality is enforced rather than aspirational.

The one-line ask: Approve a timeboxed spike to fork Kit, build one real endpoint end-to-end through the generator and all five gates, and report back on ramp cost and gate friction before we commit it as the standard for new API services.