Hey everyone, I'm just starting out with ResearchRabbit and I'm hitting a snag right at the beginning.
My main reference library is in Zotero (a few hundred papers). I really want to try ResearchRabbit for its discovery features, but I don't want to manually re-enter all my starting papers. The website mentions "import from reference manager" but it's a bit vague. Has anyone successfully moved their Zotero collection over?
I tried exporting my Zotero library as a BibTeX (.bib) file and using the ResearchRabbit import function. It seemed to accept the file, but then only about 10% of the papers appeared in my collection. The rest were just... missing. No error message.
Here's a sample of the BibTeX format I exported:
```bibtex
@article{author2023title,
title={An interesting paper},
author={Author, A. and Coauthor, B.},
journal={Journal of Data Science},
volume={10},
number={2},
pages={100--120},
year={2023},
publisher={Some Publisher}
}
```
Is this the correct approach, or is there a specific Zotero export setting I'm missing? Maybe a CSV route is better?
I'm hoping I'm not stuck manually adding everything. If importing is possible, it would save me hours and let me jump straight into testing the visualization and discovery tools. Any tips from those who've done this before would be super helpful!
Oh yeah, the missing 90% thing is frustrating. I had a similar problem trying to import from Mendeley.
Someone in their Discord said the BibTeX import can choke on special characters or super long field entries. Did you try the "export to .ris" option from Zotero instead? I think that's the format ResearchRabbit really prefers. Might work better.
Let me know if the .ris file does any better. If you still get missing papers, maybe it's a bug they need to fix.
If the tool can't parse a standard BibTeX entry like that, it's broken.
BibTeX is the lingua franca for this. The "preferred .ris" suggestion is a workaround for their bad import logic. I'd bet the missing 90% are due to:
* Weak field matching on DOIs or titles
* Silently dropping entries on any parse error
Test it. Export a tiny Zotero collection of 5 known papers. See which ones fail. That's your proof the feature is half-baked. If they can't get data ingestion right, how much trust do you put in their discovery algorithms?
If it's not a retention curve, I don't care.
Welcome to the community. You're on the right track, but the .bib route can be tricky.
User570's suggestion is good. Try exporting from Zotero in RIS or EndNote XML format. ResearchRabbit's parser often handles those more cleanly than BibTeX. Also, before importing, make sure all your Zotero entries have DOIs populated if possible. The system matches best on those.
If a batch import still fails, don't manually enter hundreds. Split your library into smaller chunks (like 20-30 papers) and import them one at a time. You'll quickly see if a specific subset is causing the hang-up. That's a more practical diagnostic step than assuming the whole feature is broken. Let us know how it goes with the RIS file.
Keep it constructive.
I understand the frustration with parsing standards, but calling a feature "broken" based on BibTeX alone is a bit of an overgeneralization. BibTeX is a standard, but it's also a famously loose one with hundreds of variant implementations and optional field mappings.
The real issue isn't necessarily a broken parser, but the cost of the matching operation that happens after the parse. ResearchRabbit isn't just ingesting a static record, it's attempting to match each entry against its own internal graph for connection and metadata enrichment. If the match confidence on a DOI or title is below a certain threshold, the entry is often silently dropped to avoid polluting a user's collection with low-confidence duplicates. That's a design trade-off, not necessarily a bug.
A better test than a 5-paper sample would be to compare the failure rate between entries with clean, verified DOIs and those without. I'd predict near 100% success for the former. The silent drop on parse error is poor UX, but the underlying problem is likely an economic one: the compute cost of fuzzy matching on hundreds of incomplete records versus the value of those matches.
Spreadsheets or it didn't happen.