Building Rate Limiting: Protecting the AI Agent Without Hurting Real Travelers

A traveler rapid-fired 50 search queries in a conversation and hit a wall. She was planning a complex group trip and was genuinely comparing options across many dates and destinations. From our system's perspective, she looked indistinguishable from an abuse pattern. From her perspective, she was just doing what the product encouraged: having a conversation with the agent about travel.

Rate limiting for an AI agent is harder than for traditional APIs because the usage patterns of legitimate power users overlap significantly with abuse patterns. Both involve rapid, repeated API calls. The challenge is telling them apart.

Why AI agents need different rate limits

A single chat message from a traveler can trigger the agent to call three to seven external APIs. A search message might invoke a flight search tool, a hotel search tool, a weather check, and a visa requirement lookup, each hitting a different external provider. This amplification means that the rate limit on the chat endpoint must account for the downstream load on providers, not just the inbound message rate.

We implemented five tiers of rate limiting, each calibrated for its specific use case. The general API tier allows 100 requests per 15 minutes, covering standard page loads and data fetches. The authentication tier is tighter at 10 attempts per 15 minutes to prevent credential stuffing. The chat tier allows 30 messages per minute, which is generous enough for rapid-fire planning conversations but catches automated abuse. The booking tier limits to 5 attempts per hour because legitimate travelers rarely book more than a few times per session. The payment tier caps at 10 requests per minute as an additional fraud prevention layer.

Protecting upstream providers

Our rate limits are not just about protecting our own infrastructure. They protect the upstream providers whose APIs we depend on. Travel data providers, payment processors, and other services each have their own rate limits. If our agent exceeds those limits, our entire platform degrades because the tools stop working.

We maintain our internal limits below our provider allocations with enough headroom for traffic spikes. When approaching a provider limit, we queue requests rather than failing them, smoothing the load while maintaining the traveler experience. The traveler might notice a slightly longer wait for search results but will not see an error message.

Avoiding false positives

The group trip planner who hit the rate limit was a false positive. She was a legitimate power user whose behavior triggered a threshold designed for abuse prevention. False positives damage trust and frustrate exactly the travelers who are most engaged with the product.

We address false positives through burst allowances and progressive throttling. Burst allowances let travelers exceed the sustained rate limit briefly during intense planning sessions. Progressive throttling slows responses rather than blocking them entirely, giving power users a degraded but functional experience instead of a hard stop.

Rate limit error messages matter more than most error messages. "429 Too Many Requests" tells the traveler nothing useful. "You're searching fast! Try again in 30 seconds. Here are your results so far." respects the traveler's intelligence and provides a clear path forward.

Rate limiting is invisible infrastructure when it works correctly. Travelers never think about it, providers stay within their quotas, and abuse is prevented without collateral damage. When it works incorrectly, the traveler who is most excited about your product becomes the one most frustrated by your infrastructure.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.