Skip to main content
Formbricks applies request rate limits to protect against abuse and keep API usage fair. Rate limits are scoped by identifier, depending on the endpoint:
  • IP hash (for unauthenticated/client-side routes and public actions)
  • API key ID (for authenticated API calls)
  • User ID (for authenticated session-based calls and server actions)
  • Organization ID (for follow-up email dispatch)
When a limit is exceeded, the API returns 429 Too Many Requests.

​
Management API Rate Limits

These are the current limits for Management APIs:
Route GroupLimitWindowIdentifier
/api/v1/management/* (except /api/v1/management/storage), /api/v1/webhooks/*, /api/v1/integrations/*, /api/v1/management/me100 requests1 minuteAPI key ID or session user ID
/api/v2/management/* (and other v2 authenticated routes that use authenticatedApiClient)100 requests1 minuteAPI key ID
POST /api/v1/management/storage5 requests1 minuteAPI key ID or session user ID

​
All Enforced Limits

ConfigLimitWindowIdentifierUsed For
auth.login10 requests15 minutesIP hashEmail/password login flow (/api/auth/callback/credentials)
auth.signup30 requests60 minutesIP hashSignup server action
auth.forgotPassword5 requests60 minutesIP hashForgot password server action
auth.verifyEmail10 requests60 minutesIP hashEmail verification callback + resend verification action
api.v1100 requests1 minuteAPI key ID or session user IDv1 management, webhooks, integrations, and /api/v1/management/me
api.v2100 requests1 minuteAPI key IDv2 authenticated API wrapper (authenticatedApiClient)
api.client100 requests1 minuteIP hashv1 client API routes (except /api/v1/client/og and storage upload override), plus v2 routes that re-use those v1 handlers
storage.upload5 requests1 minuteIP hash or authenticated IDClient storage upload and management storage upload
storage.delete5 requests1 minuteAPI key ID or session user IDDELETE /storage/[environmentId]/[accessType]/[fileName]
actions.emailUpdate3 requests60 minutesUser IDProfile email update action
actions.surveyFollowUp50 requests60 minutesOrganization IDSurvey follow-up email processing
actions.sendLinkSurveyEmail10 requests60 minutesIP hashLink survey email send action
actions.licenseRecheck5 requests1 minuteUser IDEnterprise license recheck action

​
Current Endpoint Exceptions

The following routes are currently not rate-limited by the server-side limiter:
  • GET /api/v1/client/og (explicitly excluded)
  • POST /api/v2/client/[environmentId]/responses
  • POST /api/v2/client/[environmentId]/displays
  • GET /api/v2/health

​
429 Response Shape

v1-style endpoints return: 
{
  "code": "too_many_requests",
  "message": "Maximum number of requests reached. Please try again later.",
  "details": {}
}
v2-style endpoints return: 
{
  "error": {
    "code": 429,
    "message": "Too Many Requests"
  }
}

​
Disabling Rate Limiting

For self-hosters, rate limiting can be disabled if necessary. We strongly recommend keeping it enabled in production. Set: 
RATE_LIMITING_DISABLED=1
After changing this value, restart the server.

​
Operational Notes

  • Redis/Valkey is required for robust rate limiting (REDIS_URL).
  • If Redis is unavailable at runtime, rate-limiter checks currently fail open (requests are allowed through without enforcement).
  • Authentication failure audit logging uses a separate throttle (shouldLogAuthFailure()) and is intentionally fail-closed: when Redis is unavailable or errors occur, audit log entries are skipped entirely rather than written without throttle control. This prevents spam while preserving the hash-integrity chain required for compliance. In other words, if Redis is down, no authentication-failure audit logs will be recorded—requests themselves are still allowed (fail-open rate limiting above), but the audit trail for those failures will not be written.