What is the lowest safe API_THROTTLE_RATE?
For a typical low‑traffic NetBox instance that sees under 50 requests per hour per user, a value of 200 requests per hour (200/hr) is a safe starting point. This rate keeps the API_THROTTLE_RATE far above the bursty traffic that automation scripts or the browsable UI may generate, while still reducing the per‑second load compared to the default “no throttling” state.
If your environment is even quieter (e.g., a single‑user lab installation), you can drop the limit to 100/hr or 50/hr without seeing 429 responses. The key is to monitor the Throttle warnings in the NetBox log after each change.
Why 200/hr is a good baseline
- NetBox’s default DRF throttle class counts requests per second; 200/hr equates to <0.06 requests/sec, which is far below the burst capacity of most scripts.
- Automation scripts that poll the API every 30 s will make ~120 requests per hour, comfortably under 200.
- UI interactions (page loads, form submissions) are typically a handful per minute, adding only a few dozen requests a day.
How to test UI impact before production
- Clone the configuration:
# Make a copy of the settings file
cp /opt/netbox/netbox/netbox/settings.py /opt/netbox/netbox/netbox/settings.py.bak
- Adjust the throttle rate in
settings.py:
REST_FRAMEWORK = {
'DEFAULT_THROTTLE_RATES': {
'user': '200/hour',
'anon': '10/hour',
},
'DEFAULT_THROTTLE_CLASSES': [
'rest_framework.throttling.UserRateThrottle',
'rest_framework.throttling.AnonRateThrottle',
],
}
- Restart NetBox and verify the setting is active:
sudo systemctl restart netbox
sudo journalctl -u netbox -f | grep -i throttle
- Simulate typical usage:
- Check the logs for any
Throttle warnings. If none appear, the UI remains responsive and the throttle rate is safe.
Can NetBox apply different limits to specific views or clients?
Out of the box, NetBox applies the global API_THROTTLE_RATE to all endpoints. However, because NetBox uses Django REST Framework (DRF), you can:
- Define custom throttle classes that inspect the request path or a custom header (e.g.,
X-Client-Id) and set a rate accordingly.
- Assign those classes to specific viewsets via the
throttle_classes attribute in the view definition. This requires editing NetBox’s source or creating a plugin that overrides the viewset.
- Use a reverse‑proxy (NGINX, Apache, Traefik) to enforce per‑IP or per‑path limits with modules like
limit_req_zone or mod_reqtimeout. The proxy must forward the X-Forwarded-For header so that DRF can distinguish users.
Note that background workers (RQ, scheduled reports) bypass DRF throttling entirely, so any limits you set will not affect them.
What diagnostic detail is still missing?
To fine‑tune the throttle rate precisely, please provide the approximate number of API requests your automation scripts make per hour, and the typical frequency of UI page loads. This will help determine whether 200/hr is sufficient or if a lower value is safe.
netbox