BerriAI/litellm · error · HTTPException
Internal Server Error
Error message
Internal Server Error
What it means
Raised as HTTPException 500 in the example_logging_api FastAPI app — a reference implementation showing how to build a custom /log-event callback receiver for litellm proxy logging callbacks. Any exception while parsing the inbound request (most commonly request.json() failing on a non-JSON body) is converted to a bare 500 with no detail.
Source
Thrown at enterprise/litellm_enterprise/enterprise_callbacks/example_logging_api.py:21
app = FastAPI()
@app.post("/log-event")
async def log_event(request: Request):
try:
print("Received /log-event request") # noqa
# Assuming the incoming request has JSON data
data = await request.json()
print("Received request data:") # noqa
print(data) # noqa
# Your additional logic can go here
# For now, just printing the received data
return {"message": "Request received successfully"}
except Exception:
raise HTTPException(status_code=500, detail="Internal Server Error")
if __name__ == "__main__":
import uvicorn
uvicorn.run(app, host="127.0.0.1", port=8000)
View on GitHub (pinned to 6c2dcb801b)
Solutions
- Treat this as example code — do not deploy it unmodified in production; copy it into your own service and add real error handling.
- Reproduce the failing payload from the proxy logs and validate it parses as JSON.
- Ensure the sender sets Content-Type: application/json.
- Replace the bare except with one that logs the exception (e.g. via app logger / exception(logger)) before returning 500.
Example fix
# before
except Exception:
raise HTTPException(status_code=500, detail="Internal Server Error")
# after
except Exception:
import logging
logging.exception("failed to process /log-event payload")
raise HTTPException(status_code=400, detail="Invalid JSON payload") Defensive patterns
Strategy: try-catch
Try / catch
@app.post("/log-event")
async def log_event(request: Request):
try:
data = await request.json()
except json.JSONDecodeError as e:
logging.warning("invalid callback payload: %s", e)
return {"status": "ignored"} # never 500 the proxy's callback sender
return {"message": "ok"} Prevention
- Never deploy the example logging API unmodified — add real parsing and error handling.
- Always send callbacks with Content-Type: application/json.
- Return 2xx for ignorable payloads so the proxy's callback sender does not retry spam.
- Log request bodies on failure so payload-shape changes are debuggable.
When it happens
Trigger: The litellm proxy is configured with a generic logging callback POSTing to this example server, and a callback payload arrives that is not valid JSON (content-type mismatch, truncated body), causing await request.json() to raise. This is example code, not production API surface.
Common situations: Users running the example callback server as-is and sending test events with curl without a JSON content-type; proxy versions whose callback payload shape changed; treating this demo server as a production logging endpoint.
Understand the failure class
- HTTP status errors: handling 4xx and 5xx responses — how to handle 4xx and 5xx responses properly.
Related errors
- Invalid content moderation response: {redacted_text}
- Error saving email settings to general_settings: {str(e)}
- Keyword banned. Keyword={word}
- File not found. blocked_user_list={blocked_user_list}
- An error occurred: {str(e)}, blocked_user_list={blocked_user
AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15).
Data as JSON: /api/errors/851c031f99f73942.
Report an issue: GitHub.