What this prompt does
This prompt designs an API versioning and rate-limiting system for a Laravel API that has outgrown being internal-only. It covers a versioning strategy with backward compatibility, rate limiting via Laravel's Rate Limiter, API key management (generation, rotation, revocation), per-key usage tracking, tiered limits by plan, deprecation headers and sunset dates, auto-generated docs, and an ordered middleware stack. It also includes a usage-analytics dashboard and quota alerting.
The variables define policy and infrastructure. [versioning_strategy] picks how versions are expressed (URI prefix like /api/v1), [rate_limits] sets the concrete throttle values, and [storage] decides where usage is tracked — often Redis with rollups to MySQL. [plan_tiers] drives tiered limits so a free key and a pro key are throttled differently. The prompt insists on a specific middleware order — auth, then rate limit, then version, then transform — because that ordering changes behavior more than people expect: rate limiting before auth, for instance, lets unauthenticated traffic burn quota. Designing the deprecation workflow early is what prevents painful breaking changes later.
When to use it
- Opening a previously internal API to external consumers who need stable versions
- Adding rate limits that differ by subscription tier
- Issuing, rotating, and revoking API keys for third-party developers
- Tracking usage per key and endpoint for billing or quota enforcement
- Establishing a deprecation workflow with sunset headers before you ship v2
- Standardizing the middleware order so auth, throttling, and versioning compose predictably
Example output
You get a versioning scheme matching [versioning_strategy], rate-limiter definitions enforcing your [rate_limits], an API-key system with generation/rotation/revocation, usage tracking backed by [storage], tiered limits keyed to [plan_tiers], deprecation and sunset response headers, an approach to auto-generating docs, and a composed middleware stack in the prescribed order. A usage dashboard and quota-threshold alerting round it out. The result reads as an API governance layer, not just a throttle annotation on a few routes.
Pro tips
- Pick
[versioning_strategy]deliberately: URI prefixes are the most transparent for consumers, header-based versioning is cleaner but harder to debug - Express
[rate_limits]per tier explicitly (60/min free, 600/min pro) so the generated limiter maps cleanly to[plan_tiers] - Use
[storage]that can handle write volume — Redis for counters with periodic rollups to MySQL keeps tracking fast without bloating the database - Respect the auth before rate-limit ordering; flipping it lets anonymous traffic consume authenticated quota
- Ship deprecation and sunset headers the moment you introduce a new version, not when you're ready to remove the old one
- Verify the auto-generated docs actually match your routes; treat generation as a draft you proofread, not a source of truth
