Error handling
HTTP error codes
| Code | Meaning | Common cause | Recommended action |
|---|---|---|---|
| 400 | Bad Request | Missing required field medical_note or invalid request format | Ensure medical_note field is provided (required) |
| 401 | Unauthorized | Invalid or expired token | Verify your Bearer token and that it’s active |
| 413 | Payload Too Large | medical_note exceeds 50KB or pdf_file exceeds 5MB decoded | Reduce input size or split content |
| 422 | Unprocessable Entity | Invalid PDF structure, malformed base64 data, invalid mime_type | Validate PDF file structure and encoding |
| 429 | Too Many Requests | Rate limit exceeded | Wait and retry with exponential backoff |
| 500 | Internal Server Error | Unexpected server error, database issues, misconfiguration | Retry with exponential backoff; if persists, report run_id |
| 503 | Service Unavailable | AI service temporarily unavailable | Retry after a few seconds |
| 504 | Gateway Timeout | Request exceeded 10-minute processing time limit | Reduce input size or split content |
Error response format
All errors follow this consistent structure:Error fields
| Field | Description |
|---|---|
success | Always false for error responses |
error | Error name/type (e.g., “Bad Request”, “Unauthorized”) |
details | Detailed error message explaining what went wrong |
Retry strategy
When to retry?
Yes, retry:- 5xx errors (500, 502, 503, 504)
- 429 error (Too Many Requests)
- Network/timeout errors
- 4xx errors except 429 (client errors)
- 401 error (invalid token)
- 422 error (invalid schema)
Exponential backoff
Python implementation
JavaScript implementation
Tracking and auditing
Using run_id for debugging
Every response includes a uniquerun_id that you should store for tracking and debugging:
Deduplication by content hash
To avoid processing the same note multiple times, use content hashing:Optional tracking headers
Use thedoctor and patient headers to enhance audit trails: