API Rate Limiting and Abuse

Pathrule3 Rules • 1 Memory

API rate limiting and abuse protection must bound more than requests per second because authenticated callers can still exhaust compute, storage, third-party spend, or scarce business actions. This bundle defines identity-aware budgets, workload limits, failure responses, and observable exceptions. Unlike REST API Design, it owns adversarial consumption and overload behavior rather than resource shapes and HTTP contracts.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

src/

middleware/

Key limits to authenticated and network identities

api/

Bound work as well as request count

Make throttling responses safe to retry

Rate policies follow business operations

Rules

Key limits to authenticated and network identities/src/middlewarehighstrictRate budgets use both account and network signals instead of trusting a single mutable identifier.

1	Rate budgets use both account and network signals instead of trusting a single mutable identifier. A single IP key punishes shared networks and is trivial to evade, while an account-only key lets unauthenticated endpoints burn resources. Enforce this boundary in /src/middleware so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Key authenticated traffic by tenant or account and add a secondary network or device dimension for anomaly containment.
4	- Keep login, recovery, signup, search, export, and write operations in separate buckets with policy names visible in code.
5	- Never accept a caller-provided header as the authoritative identity unless a trusted proxy overwrites and authenticates it.
6	- Return the same authorization-safe error shape whether the identity exists or not.
7
8	Verification: Exercise shared NAT traffic, account rotation, missing proxy headers, and a valid burst; confirm each bucket isolates only the intended subject.

Bound work as well as request count/src/apihighstrictEvery endpoint caps the dimensions that drive CPU, memory, storage, queue depth, and vendor cost.

1	Every endpoint caps the dimensions that drive CPU, memory, storage, queue depth, and vendor cost. A cheap request counter does not stop oversized pages, batched queries, decompression bombs, repeated exports, or calls that trigger paid services. Enforce this boundary in /src/api so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Set explicit payload, page-size, batch, file, fan-out, and execution-time limits at the request boundary.
4	- Charge weighted tokens for expensive operations instead of treating a cache hit and a full export as equal work.
5	- Cap concurrent in-flight work per tenant and reject before enqueueing when its budget is exhausted.
6	- Put hard spend or quota guards around SMS, email, model, map, and other metered downstream calls.
7
8	Verification: Load-test the maximum accepted shape and one value beyond every bound; verify rejection happens before allocation, enqueue, or vendor invocation.

Make throttling responses safe to retry/src/apihighstrictA rejected caller receives a stable status, bounded retry guidance, and no partial side effects.

1	A rejected caller receives a stable status, bounded retry guidance, and no partial side effects. Silent connection drops and arbitrary delays cause clients to retry in lockstep, while a late rejection can duplicate writes or paid work. Enforce this boundary in /src/api so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Use HTTP 429 for policy throttling and emit Retry-After only from a server-controlled calculation.
4	- Add jitter to client guidance and cap wait values so corrupt policy data cannot freeze a client indefinitely.
5	- Reserve capacity for health checks, control-plane work, and emergency operators instead of disabling the limiter during incidents.
6	- Log the policy key and outcome without recording secrets, raw tokens, or unnecessary personal identifiers.
7
8	Verification: Replay a throttled idempotent request after Retry-After and confirm no earlier side effect occurred; verify metrics distinguish rejected, delayed, and admitted work.

Memories

Rate policies follow business operations/src/apiLimits attach to named business operations rather than whichever URL currently exposes them.

1	Limits attach to named business operations rather than whichever URL currently exposes them. Routes change, aliases coexist, and GraphQL or RPC calls multiplex many operations through one endpoint, so URL-only policies drift away from the actual cost and abuse surface.
2
3	Resolve a stable operation identifier after authentication and before work begins. Keep its budget, cost weight, concurrency cap, and exception owner in one reviewed policy table. Share the same operation key across REST, GraphQL, workers, and internal retries so a caller cannot switch transports to reset a budget. Keep the decision explicit at /src/api; moving it into an incidental caller makes behavior depend on which route happened to execute first.
4
5	See /src/middleware for identity keys and the API abuse pattern for response behavior. That related boundary consumes this decision and carries the evidence that proves it still holds.

Why this pattern

Agents often add one IP counter and call an API protected, leaving authenticated abuse, expensive operations, queue growth, and third-party spend unbounded.

Built for Teams operating public or partner APIs with variable-cost work and abuse-sensitive business flows.

Keeps your assistant from:

One global limit that lets attackers rotate identities or IPs
Unbounded payload, pagination, concurrency, or downstream spend
Retries that amplify overload because clients receive no backoff contract

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25