API Rate Limiting Strategies for WordPress

If your WordPress site exposes REST API endpoints — especially form submission endpoints — rate limiting is not optional. Without it, a single script can flood your server with thousands of requests per second.

The Transient Approach

For simple rate limiting without external dependencies, WordPress transients work well:

function check_rate_limit(string $prefix, int $max = 5, int $window = 3600): bool {
    $key   = $prefix . "_" . md5($_SERVER["REMOTE_ADDR"] ?? "unknown");
    $count = (int) get_transient($key);

    if ($count >= $max) {
        return false; // Rate limited
    }

    set_transient($key, $count + 1, $window);
    return true; // Allowed
}

This allows 5 requests per hour per IP address. Simple, effective, and works on any WordPress host.

Server-Level Rate Limiting

For high-traffic sites, rate limiting should happen at the web server level before PHP even starts:

# Nginx rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /wp-json/ {
    limit_req zone=api burst=20 nodelay;
    # ... existing config
}

This is more efficient than PHP-based limiting because Nginx handles it before any PHP processing occurs.

Layered Defense

I use both approaches: Nginx rate limiting for general API protection and PHP transients for stricter limits on sensitive endpoints like form submissions and authentication. The combination handles both automated attacks and abuse without affecting normal users.