I've been integrating ChatPDF's API into a document processing pipeline and have hit a consistent issue: when processing PDFs above a certain size (empirically, around 50 pages or 15MB), the API frequently returns empty or truncated responses. The status code is 200, but the `content` field in the JSON response is either an empty string or contains only a fraction of the expected analysis.
My initial hypothesis was a timeout on my end, but I've ruled that out. My client is configured with generous timeouts, and I'm not seeing network errors. The behavior suggests a server-side processing limit or a silent failure within ChatPDF's own systems.
Here's a simplified version of my request for context:
```python
import requests
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
payload = {
"sourceId": "file_abc123", # Previously uploaded large PDF
"messages": [
{
"role": "user",
"content": "Summarize the key points from the document."
}
]
}
response = requests.post("https://api.chatpdf.com/v1/chats/message",
json=payload,
headers=headers,
timeout=120)
print(response.json()) # Output: {'content': ''}
```
Has anyone else encountered this ceiling for file size or complexity? I'm looking for:
1. Confirmation of any documented or undocumented limits on file size, page count, or token count for the API.
2. Potential workarounds—would pre-chunking the PDF into smaller sub-documents before upload be the recommended approach?
3. Any server-side logs or error details that might be obscured from the API response.
The documentation mentions file size limits for uploads, but not for subsequent processing during chat interaction. This makes debugging difficult, as the failure is silent.
—J
—J
Check your chunking logic. Large PDFs might be getting split weird on their end, causing the response to drop sections.
Also, try a simpler test query like "what is the title?" to see if the issue is with the complexity of the summarization request itself.
Benchmarks or bust.
That's a good point about chunking. I hadn't considered that their internal processing might be splitting the document differently for large files.
When you say "try a simpler test query," do you mean I should use the exact same large file but just ask for the title? That would be a clever way to isolate if it's a size issue or a request complexity issue. I'll give that a shot.
It's still strange the response comes back empty instead of with an error, though. Wouldn't a time-out or a processing failure usually throw a different status code?
Yeah, the empty content with a 200 status is the weird part. I've seen something similar with a different API where large files triggered an internal processing queue, and successful responses just meant the job was accepted, not completed. The actual content came in a separate webhook callback later.
Have you checked if ChatPDF has any async or webhook options for large documents? Their docs might mention a different endpoint for batch processing. If not, you could try adding a `wait` parameter to your request, if they support it.
Also, what's your retry logic look like? If it's a silent failure on their end, a simple retry with a delay might actually get you a full response sometimes.
Learning by breaking