Restore a Broken LLM API Integration
A real ai/ml problem you debug end to end in a live cloud workspace, then show on your portfolio. No tutorial, no toy app - a broken system that behaves like production.
The scenario
The text summarization script is broken. When you run it, you get either a connection error or a "model not found" response from the LLM service.
The broken code you start with
API_URL = "http://.../v1/completions" # wrong port + path
payload = {
# missing "model" - the API rejects the request
"prompt": text,
}
response = requests.post(API_URL, json=payload, timeout=60)What this teaches you
What you did: The client was hitting :8080/chat/completions but the service exposes :8080/v1/chat/completions, and the JSON body was missing the required model field. Fixed both and the request went through.
Why it matters: Every OpenAI-compatible API uses the same payload shape - once you know the contract (/v1/ path, model + messages fields), you can swap providers by changing one env var.
In the real world: Day-one integration tasks look exactly like this. You read a README that's 80% complete, write the obvious code, hit a cryptic 404, and spend 20 minutes finding out the docs cut off the version prefix. Senior engineers learn to open the OpenAPI spec directly and skip the README.
What you'll practice
- Calling an OpenAI-compatible completions endpoint
- Sending a correct request body (model + prompt)
- Debugging a failing model call
Why this impresses a hiring manager
- This is a real python problem teams hit in production - not a synthetic puzzle.
- It shows you can diagnose and fix a AI/ML issue in a live system end to end.
- It lands on your portfolio as a scenario a hiring manager can open and click through.
Restored the LLM API integration by correcting the endpoint path and adding the required model field to the request payload
Keep going
Build this project free
You're in a real cloud workspace in 30 seconds. Fix it, and it lands on your portfolio.
Start this project →