Overview
Request Logs give you full visibility into exact payloads — what was sent to the AI provider and what came back. This is your most detailed debugging tool, but it's only effective if you know what to look for.
Request body inspection
What to verify
When inspecting a request body, check these fields:
JSON
1{2 "model": "gpt-4o",3 "messages": [4 {"role": "system", "content": "..."},5 {"role": "user", "content": "..."}6 ],7 "temperature": 0.7,8 "max_tokens": 500,9 "response_format": {10 "type": "json_schema",11 "json_schema": { ... }12 }13}Checklist:
- Model — Is the correct model specified?
- Messages — Are system and user messages present and correct?
- Temperature — Is it appropriate for the task? (0 for deterministic, 0.7-1.0 for creative)
- Max tokens — Is there enough room for a complete response?
- Response format — If using structured outputs, is the schema correct?
Common request issues
| Issue | Symptom | What to look for |
|---|---|---|
| Missing system prompt | Inconsistent behavior | Empty or missing system message |
| Truncated context | Incomplete responses | Conversation history cut short |
| Wrong model | Unexpected quality | Model name doesn't match intent |
| Bad temperature | Too random or too rigid | Temperature too high (>1.0) or 0 |
| Schema mismatch | Parsing errors | response_format doesn't match expected output |
Response body inspection
Successful response
JSON
1{2 "id": "chatcmpl-abc123",3 "choices": [{4 "message": {5 "role": "assistant",6 "content": "Here is the AI response..."7 },8 "finish_reason": "stop"9 }],10 "usage": {11 "prompt_tokens": 1250,12 "completion_tokens": 380,13 "total_tokens": 163014 }15}Key fields to check:
finish_reason—"stop"means complete,"length"means truncated (increasemax_tokens)usage— Are token counts reasonable for the request?content— Does the response match expectations?
Error response
JSON
1{2 "error": {3 "type": "invalid_request_error",4 "message": "This model's maximum context length is 128000 tokens. However, your messages resulted in 135420 tokens.",5 "code": "context_length_exceeded"6 }7}Common errors:
context_length_exceeded— Trim conversation historyrate_limit_exceeded— Back off or add provider capacityinvalid_api_key— Update credentialscontent_filtered— Review and modify prompt content
Comparison techniques
Side-by-side comparison
When debugging unexpected results, compare a failing request with a known-good one:
- Find a successful request for the same task
- Open both request bodies side-by-side
- Diff the two payloads — look for:
- Different system prompts
- Missing or extra messages
- Changed parameters (temperature, max_tokens)
- Modified structured output schema
Before/after comparison
When a workflow change causes issues:
- Find a request from before the change
- Find a request from after the change
- Compare the request bodies to see what changed
- The difference usually reveals the issue
Reproducing issues
Using Request Logs data to reproduce
- Copy the exact request body from the failing request (use the Copy button)
- Paste it into the Playground
- Run it to see if the issue reproduces
- If it does, modify the request to isolate the cause:
- Change one field at a time
- Test each change until the response improves
- The field that fixed it reveals the root cause
Creating test cases
Once you've identified the issue:
- Save the problematic request body as a test case
- Document the expected vs. actual response
- After fixing, run the test case again
- Confirm the response now matches expectations
Using the tree view
For complex, deeply nested payloads, use the Preview (tree view) instead of raw JSON:
- Expand/collapse sections — Focus on specific parts of the payload
- Navigate large message arrays — Find specific messages quickly
- Inspect structured output schemas — Verify complex JSON schemas
- Compare nested fields — Easier to spot differences in tree view
Next steps
- Using Timeline Context — Complete lifecycle view
- Debugging Production Issues — Step-by-step debugging guide
- Back to Best Practices — Return to the overview