Rate limiting and abuse prevention for public AI chatbots and APIs
Protect public AI features from scraping, cost abuse and misuse with layered limits, token budgets, bot controls and a clear response playbook.
This is for founders, product heads and platform engineers running AI chatbots on websites, WhatsApp, or public APIs. Unlike a normal web page, every AI request has a direct cost and can be used for things you never intended: scraping your knowledge base, running free general-purpose queries, or flooding the service until real users are blocked. This post sets out practical limits, monitoring and response steps you can put in place before launch, so abuse becomes visible and contained rather than discovered on the monthly invoice.
A real estate developer launches a website chatbot to answer project questions. Within weeks, model spend climbs sharply. Logs show a handful of sessions sending long, unrelated requests around the clock, using the bot as a free general assistant. Another script systematically asks about every project to copy the price list and brochure content.
The team had a simple requests-per-minute limit per IP, which scripts bypassed by rotating addresses. There was no per-session token budget, no topic restriction, and no spend alert, so the first sign of trouble was the bill. Turning the bot off entirely was the only option they had, which also cut off genuine buyers.
A multi-specialty hospital group in Delhi NCR launched a website and WhatsApp chatbot for appointment and doctor queries. After a promotional campaign, usage jumped and part of it was automated traffic asking unrelated questions. The platform team added per-session token budgets, tighter limits for anonymous web visitors, a topic check that redirected off-topic requests, and edge bot challenges on the web widget. Finance set a daily spend alert with a named on-call owner. After the change, genuine patients continued booking without friction, automated sessions were throttled early, and when a later spike occurred the team followed the playbook and tightened anonymous limits within minutes instead of switching the bot off.
What limits should we start with?
Base them on observed genuine usage during pilot testing, then add headroom. Anonymous visitors should get tighter limits than signed-in users or paying tenants. Review limits after launch and after each campaign, because normal patterns change.
Will a topic check annoy real users?
Not if it is tuned to your use case and replies helpfully, pointing users to what the bot can do or to a human contact. Test it with real questions from sales and support before launch.
Should WhatsApp chatbots have the same controls?
Yes, adapted to the channel. Phone numbers give you a stable identity for per-user limits and budgets, and the messaging platform's own policies apply. Watch for unusual volumes from new numbers or repeated identical messages.
Who should own abuse response for AI features?
The platform owner runs the playbook and adjusts limits, finance owns spend alerts and budgets, and security handles edge controls and investigation. Name a primary and backup person for each so alerts are never orphaned.
Want this fixed in your business?
Send the workflow. You get a scope and a fixed price within two working days — or a straight answer that it isn't a fit.