400 errors

# 400 error behavior

• 400 errors appear immediately after the browser sends the request
• They often surface during integration work with third-party services or new client-side code that posts JSON or form data
• They can be triggered by your application framework, by a reverse proxy, or by the fortrabbit edge when the request is malformed

Most 400 responses indicate something is wrong with the request that is sent, not with the platform itself. Work through the following checks first:

# Check the request that is sent

• Inspect the request in your browser developer tools or with curl -v.
• Ensure the Host header matches your App domain. Requests to the wrong hostname or without TLS will be rejected.
• Validate query strings and payloads: truncated JSON bodies, illegal characters, or an unexpected content type will cause a 400.

# Review application level validation

• Many frameworks respond with 400 when CSRF tokens or form validations fail. Confirm that cookies, sessions, and CSRF headers are present.
• Double-check any custom middleware you added. Rate limiters and API gateways frequently send a 400 when a prerequisite header (API key, signature) is missing.
• Compare with your local environment: reproduce the failing request locally to see if the framework reports the same problem.

# Check the logs

• Application and web server logs will often mention the exact reason. See Logs for where to find them.
• Consider enabling verbose logging temporarily to capture raw request details (remember to disable again afterwards).

# It could also be something on our side

Less common, but still possible: a transient network hiccup or edge misconfiguration could cause 400 responses. Have a look at status.fortrabbit.com for active incidents, and contact support if everything above checks out and the issue persists.