I've been integrating the Scholarcy API into a documentation pipeline for automated research paper summarization. The workflow is straightforward: upload a PDF, receive a structured JSON response, and parse the `summary` field for downstream processing. However, I've encountered a persistent and puzzling issue where valid, text-based PDFs are returning a perfectly formed response object, but with an empty `summary` field.
My initial troubleshooting followed a standard isolation path:
* Verified the PDFs are not image-scans (OCR would be needed for those).
* Confirmed successful uploads and `200` OK responses from the API.
* The returned JSON includes populated `title`, `authors`, and `references` fields, indicating partial parsing success.
* Examined the raw `fullText` field in the response, which contains the complete extracted text from the PDF.
This suggests the summarization engine is receiving and processing the text, but failing to generate the condensed summary. Has anyone else run into this? My leading hypothesis is that there might be an undocumented size or structural threshold—perhaps very short or very long documents, or those with atypical section headers, cause the summary logic to exit silently.
For reference, here's the core of my Python client call and the problematic response snippet:
```python
import requests
headers = {"Authorization": f"Bearer {API_KEY}"}
with open("document.pdf", "rb") as f:
response = requests.post(
"https://api.scholarcy.com/v1/parse",
headers=headers,
files={"file": f}
)
result = response.json()
# Other fields are present, but summary is empty.
print(result.get('summary')) # Outputs: None or empty string
print(result.keys()) # Confirms 'summary' key exists
```
I'm curious if this is a known quirk with certain PDF generators or if there are specific pre-processing steps recommended before API submission. Any shared experiences or debugging approaches would be valuable for building a more robust pipeline.
--crusader
Commit early, deploy often, but always rollback-ready.