Rate limits stop abuse at well-understood thresholds. But sophisticated attackers stay under the limit — they spread requests over many IPs, slow their rate to just below detection, and still extract significant data over time. Monitoring catches this residual risk.
Key signals to monitor:
• Request volume per user/IP over 1-hour, 24-hour, and 7-day windows — flag users whose consumption is 3× or 10× their historical average.
• Systematic enumeration patterns — sequential ID traversal, alphabetical user enumeration, page=1 through page=10000.
• 429 rate — a spike in 429 responses means someone is hitting limits, which itself is a signal of attempted abuse.
• Unusual payload sizes or query complexity — requests requesting extreme page sizes or deeply nested GraphQL queries.
• Third-party cost spikes — sudden increases in AI calls, SMS sends, or email volume per user.
Alert the security team. Temporarily block the offending client. Require re-authentication or CAPTCHA. In serious cases, suspend the account and investigate whether data was exfiltrated. Log enough context (which endpoint, what parameters, how many records returned) to assess the scope of any data that was accessed.
Ask whether any of your API operations trigger costs with third parties — SMS messages, AI API calls, payment processing. Those operations need their own rate limits, separate from general API throttling.