Api Rate Limit Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for API abuse protection. Whether per-resource throttling is something we assemble from a community bundle or build on the framework's own primitives. This package represents the "buy" option and is weak on maintenance signals, so it mainly helps us close out that option.
• Platform fit — a hard gate, not a preference. Despite being described as a "Laravel/PHP package," this is a Symfony bundle targeting API Platform resources (attribute/config-driven limits per resource). If our stack is Laravel, this decision is over before scoring begins; it only resurfaces if we have (or plan) Symfony services.
• Feature scoping: per-endpoint vs. global rate limits. The bundle's value proposition is per-resource granularity, which maps to real product asks — expensive search endpoints limited tighter than cheap reads, per-tenant fairness, plan-tier quotas (free/pro/enterprise).
• Monetization and tier enforcement roadmap. Per-resource limits are the mechanism behind usage-based pricing and quota upsell. Deciding this package is inadequate forces us to schedule first-class quota work rather than assume it ships "for free."
• Risk budgeting on third-party dependencies. 68 stars, 0 dependents, last release 2021-04-27 — this is a live input to our dependency policy and our security-review threshold, not just a technical comparison.
• Migration cost estimation. If any team has already adopted it, this assessment triggers a planned exit to Symfony's native RateLimiter component (Symfony 5.2+) before the next major upgrade.

When to Consider This Package

Consider it only when all of the following hold:

• The service is Symfony + API Platform, and pinned to a version generation contemporaneous with the bundle (API Platform 2.x-era, PHP 7.x/early 8.x).
• The requirement is specifically declarative per-resource limits configured alongside resource definitions, not cross-cutting gateway policy.
• The blast radius is small — internal or low-traffic API, no contractual SLA, no PII-heavy surface.
• We are willing to vendor or fork it: the codebase is small enough to own, and we accept that we, not upstream, will patch it.
• Limits are enforced in-process only; the bundle is not a distributed/Redis-backed limiter and should not be sold as one.

Look elsewhere — decisively — when any of these are true:

• Laravel, Slim, Laminas, or plain PHP-FPM. Wrong framework; no path to adoption.
• Symfony 5.2+ / API Platform 3.x. The native RateLimiter component plus API Platform's own rate-limiting support covers this ground with framework-backed maintenance, security patches, and storage adapters (Redis, Doctrine, cache). This is the default recommendation.
• Multi-instance / horizontally scaled deployments needing shared counters and atomic enforcement.
• Anything customer-facing with an SLA, or where throttling is part of a security control (credential stuffing, scraping defense). A 2021-frozen, three-figure-star dependency should not sit on that path.
• Long-horizon roadmaps. A ~4-year-old last release with zero dependents is a maintenance liability we would inherit, not delegate.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Use the framework's native rate limiting, or enforce at the edge.

For executives: We evaluated a community add-on for per-endpoint API throttling. It is unmaintained since 2021, has no downstream users we can point to, and — despite how it was surfaced to us — is built for Symfony/API Platform rather than our stack. Adopting it would mean owning a small, stale codebase ourselves for a capability the framework now provides natively. The cost isn't the license (MIT, free); it's the maintenance and security-review surface we'd take on permanently to avoid a few days of built-in work. Recommendation: close this out and fund native rate limiting as scoped work.

For engineering: Native RateLimiter (Symfony 5.2+) gives us the same per-route/per-resource control with framework maintenance, Redis-backed shared counters, and security patching. For anything multi-instance or customer-facing, prefer edge/gateway limiting — it's cheaper to operate and survives application changes. If a spike genuinely needs this bundle's declarative API, timebox to two weeks, vendor the source, and log the exit ticket before merging.

For the roadmap: Per-resource limits are a real input to tier pricing and fairness guarantees. Treat them as a product requirement to schedule, not a package to install — that framing is what keeps quota work from silently depending on an abandoned dependency.