Api Platform Rate Limiter Laravel Package

Product Decisions This Supports

• Pricing tiers and fair-use limits. Multiple RateLimit entries now compose naturally, so a single endpoint can carry a burst cap (100/min), an hourly cap (1,000/hr) and a daily cap (10,000/day) declaratively. That maps directly onto plan tiers, trial limits and abuse ceilings without custom throttling code — a pricing/packaging decision you can now make in the resource definition rather than in a service layer.
• Quota attribution model (per-user vs per-tenant vs per-IP). The release clarifies bucket vs identity semantics and makes symfony/security-core optional: authenticated users are limited by user identity when Security is present, otherwise the package falls back to client IP. This is the decision that determines who gets billed for overage and how you answer "why was I throttled?" support tickets. It must be settled before quotas are published externally.
• Build vs buy for throttling. The package owns limit declaration and composition; it does not own storage, response headers, error UX, analytics or admin tooling. Treat it as "buy the limit algebra, build the enforcement surface."
• Roadmap sequencing. v0.2.0 is a pre-1.0 release that removes five public abstractions (DynamicLimit, DynamicCost, DynamicBucket, Identity, Condition), the Interval value object and the RateLimitChecking event. Any roadmap item that assumed a stable limits API should carry an explicit migration workstream before more limits are layered on.
• Observability ownership. Dropping RateLimitChecking removes the in-package hook teams commonly use for throttle telemetry. This forces a deliberate decision on where throttle metrics/alerts live (middleware, exception handler, or gateway) rather than inheriting it.
• Change-management policy. Because resource-level and operation-level limits now combine instead of replacing each other, a refactor to a resource can silently raise or lower effective quotas. A PM-level control worth adopting: require a quota diff in review and keep a customer-facing limits changelog.

When to Consider This Package

Consider it when:

• You expose a versioned Laravel API organised around resources and operations, and want limits declared next to the endpoint rather than in a parallel config.
• You need several simultaneous windows on one endpoint (burst + hourly + daily), which is awkward to express with framework-native throttling.
• You need tenant- or user-scoped buckets and want the bucket/identity distinction handled for you.
• Your platform team is small and hand-rolling counter storage, limit composition and identity resolution is a poor use of it.
• You can pin exact versions and absorb 0.x breaking changes on your own cadence.
• You already run Symfony Security for identity, or you have consciously accepted IP-based fallback.

Look elsewhere or defer when:

• You need a stable public API contract now. A 0.2.0 that deletes five abstractions is a signal to check release history, maintainer bandwidth and test coverage before committing — verify, don't assume.
• You depend on lifecycle events for audit or alerting; there is no replacement hook in this release.
• You need edge/gateway-grade enforcement (DDoS, WAF, global quotas) — that belongs in front of the app, not in resource metadata.
• You need a quota management product: dashboards, customer-facing usage views, self-serve limit changes. This is a code-level declaration tool.
• You require strongly consistent distributed counters — confirm the backing store's guarantees before designing anything customer-visible on top of it.
• Your team isn't on the resource/operation metadata pattern; the ergonomics depend on it.

How to Pitch It (Stakeholders)

Executive summary. This gives us declarative, in-code rate limits on our API endpoints, including stacked burst/hourly/daily caps and tenant-aware buckets — the mechanics behind tiered plans and abuse protection, without building a throttling subsystem. It is early-stage (0.x) and this release is intentionally breaking. Recommendation: adopt narrowly behind a pinned version for one or two endpoints, not as a platform-wide dependency, and revisit at 1.0.

Engineering. Less boilerplate: limits live with the resource and compose instead of overriding. Cost of upgrade: removed dynamic/identity/condition abstractions must be rewritten as typed resolver class names and an explicit bucketResolver; Interval becomes strings or DateInterval; the RateLimitChecking event must be replaced with middleware or exception-handler instrumentation. Budget a focused migration plus re-baselining of every existing quota, since resource and operation limits now add together rather than replace.

Product and Finance. We gain the ability to sell tiered limits and defend capacity with configuration rather than code. Two caveats to resolve before publishing anything customer-facing: (1) effective limits may change for existing endpoints purely from the composition change, and (2) identity falls back to client IP when Symfony Security isn't installed, which changes who is accountable for overage. Both need confirmation per environment before quotas appear in a contract or pricing page.

Risk and communications. Quota semantics are customer-facing; treat any future release that alters composition the same way as a pricing change — comms, docs and support scripts updated together. The release notes already correct misleading tenant quota documentation, which tells us the documentation is still stabilising: do not let it be the sole source of truth for published limits.