# Implement Upstash Rate Limits for JavaScript APIs

Serverless APIs need request limits that balance abuse prevention, latency, and Redis costs. This skill guides SDK integration, algorithm selection, and operational configuration with focused TypeScript examples.

## Install

```bash
npx skillstore add upstash/upstash-ratelimit-js
```

## Metadata

- Status: approved
- Slug: upstash-upstash-ratelimit-js
- Skillstore revision: r1
- Version status: missing
- Tree hash: 960447ea2fdc16c52c7bdf0298e49c05e8425ad95916504c43468366525c2998
- Author: upstash
- GitHub username: upstash
- License: MIT
- Repository: https://github.com/upstash/skills/tree/adffa8896cd8e75649366a34183ecab6156e33c0/skills/upstash-ratelimit-js
- Ref: 91cd54c30dc04e4a3cfe02dd687a03c81d0c00bc
- Supported tools: Claude, Codex, Claude Code
- Audit status: complete
- Agent install advisory: allowed
- Manual install advisory: allowed
- Artifact signature: available
- Audit attestation: unavailable
- Human verification: not\_verified
- Risk factors: network, env\_access, external\_commands
- Quality score: 77
- Quality tier: bronze
- Public page: https://skillstore.pages.dev/skills/upstash-upstash-ratelimit-js
- Manifest: https://skillstore.pages.dev/api/skills/upstash-upstash-ratelimit-js/manifest

## Capabilities

- Compare fixed window, sliding window, and token bucket algorithms, including burst behavior and multi-region constraints.
- Guide SDK integration using limit, getRemaining, resetUsedTokens, and blockUntilReady.
- Explain ephemeral caching, timeout behavior, analytics, and background task completion in edge runtimes.
- Describe tier-specific prefixes, weighted requests, and single-region dynamic limits.
- Configure deny-list checks using IP addresses, user agents, countries, and identifiers.
- Estimate Redis command usage across algorithms, cache states, analytics, protection, and multi-region replication.

## Use Cases

- Throttle a serverless API: Add per-user limits to an API route and return a 429 response when the quota is exhausted.
- Plan Redis capacity and costs: Compare algorithm command counts, cache behavior, and replication overhead before choosing a regional deployment strategy.
- Configure abuse protection: Apply deny-list checks to client metadata and account for exact matching, cached blocks, and asynchronous IP list updates.

## Prompt Templates

### Start with a basic limiter

```
Show a TypeScript Upstash rate limiter allowing five requests per user every ten seconds. Explain Redis configuration and handling rejected requests without exposing secrets.
```

### Choose an algorithm

```
Compare fixed window, sliding window, and token bucket for my API. Ask about burst tolerance, regional deployment, and Redis costs before recommending an algorithm.
```

### Review edge runtime behavior

```
Review my edge rate limiter for cache placement, timeout behavior, analytics, and pending task completion. Identify integration gaps and propose changes using bundled SDK documentation.
```

### Design tiered regional limits

```
Design limits for free and paid tenants across two regions. Compare prefixes, weighted requests, protection, and command costs, and explain consistency and dynamic-limit restrictions.
```

## Limitations

- Provides documentation and examples, not a deployed service or automated test suite; integrations require SDK packages and Redis credentials.
- Timeouts can allow requests through when Redis is slow or unavailable; the examples do not guarantee fail-closed protection.
- Multi-region operation trades strict enforcement for performance; dynamic limits and token bucket support have documented multi-region restrictions.
- Deny lists use exact matches rather than patterns or CIDR ranges; documented command counts are not live billing quotes.

## Best Practices

- Check bundled SDK documentation and source before implementing version-sensitive options, and keep Redis credentials in server-side configuration.
- Reuse limiters outside serverless handlers and complete pending background work through the runtime lifecycle.
- Choose trusted identifiers and test rejection, timeout, and regional consistency behavior against your security requirements.

## Anti Patterns

- Treating timeout success or multi-region quotas as strict abuse prevention guarantees.
- Creating a fresh ephemeral cache for every request and expecting persistent block caching.
- Assuming deny lists support CIDR ranges or patterns, or omitting client metadata required by protection checks.

## Security Audit

- Audited at: 2026-10-29T14:54:02.472\+00:00
- Summary: All 14 static findings are false positives involving documentation prose, Markdown formatting, example addresses, or legitimate Redis configuration. No evidence found of prompt injection, unauthorized command execution, credential exfiltration, or malicious intent in the reviewed files. Application integrations still require Redis credentials and deliberate timeout and consistency policies.

## Stats

- Views: 0
- Downloads: 2
- Favorites: 0
- Popularity score: 0
