If your search runs from your own server (backend search), all your search requests reach Algolia from your server's IP address. That affects both rate limiting and bot protection.
Rate limiting with backend search
Algolia rate limits apply per IP address or per userToken. With backend search, every request comes from the same IP address, so a per-IP rate limit would treat all your users as one. When a bot spikes, real users would be limited along with it.
To rate-limit each of your users separately, your backend needs to tell Algolia who the end user is on each search. Either:
-
Forward the end user's IP address in the
X-Forwarded-Forheader, so the rate limit applies per end-user IP rather than to your server's IP; or -
Send an
X-Algolia-UserTokenheader with an identifier for the end user, such as a session ID, so the rate limit applies per user token.
Either way:
- Set the header from your backend, based on the incoming request or session, rather than passing through a value the browser supplied.
- Don't use personally identifiable information, such as an email address, as the user token.
- For how to send extra headers, see Request options in the API client documentation (or Set extra header for earlier client versions).
For setting up the rate limit itself, see Why is it important to create a rate limited API key?
Bot protection on your server
You control the server that receives your users' requests, so you can filter bot traffic before it reaches Algolia:
- Web application firewall or CDN bot protection. Many WAF and CDN providers can detect and challenge automated traffic based on behaviour as well as IP address. See, for example, Cloudflare's bot protection.
- Your own limits. Add per-user or per-session limits in your backend, for example in middleware.
For more on bot patterns and mitigation, see How can I mitigate bots impacting my usage of Algolia?