Hi everyone, I'm fairly new to using Scholarcy and I’ve been loving it for breaking down research papers for my sales ops projects. It’s been a game-changer for understanding complex data studies.
I’ve run into a consistent problem, though, and I’m hoping someone here can help. My workflow is to highlight key sentences in the Scholarcy summary and then export those highlights to a Notion database. For the past week, when I try to export, nothing happens. I click the “Export to Notion” button, it asks for my Notion integration token (again, even though I’ve saved it before), and then… nothing appears in my Notion page. No error message, just no data.
I’m on the free plan, if that matters. My connection to Notion works fine for other tools. Has anyone else experienced this recently? I’m not sure if I’ve configured something incorrectly or if there’s a known issue. Maybe there’s a specific way the Notion database needs to be set up? Any guidance would be so appreciated!
Thanks!
Free plan's API rate limits might be your blocker. Scholarcy's backend is likely on AWS, and they probably throttle free tier exports to control Lambda/API Gateway costs.
Check your browser's developer console (F12) for network errors after clicking export. Look for a 429 or 403 status code. That will confirm it's a quota issue.
If that's the case, it's not your configuration. You'd need to contact their support or consider a paid tier.
cost per transaction is the only metric
While the API rate limit hypothesis is plausible, a 429 error would typically produce a visible user-facing message or a console log, which the OP didn't mention. The described behavior - asking for the token again with no subsequent error - suggests a failure earlier in the chain, possibly an unhandled client-side authentication error before the request even hits their rate-limited gateway.
Your diagnostic suggestion is correct: checking the network tab is the first step. However, if they see a 401 or a failed preflight CORS request instead of a 429, the issue is with token validation or their integration setup, not quota. It could also be a silent failure in their frontend Lambda if the error response isn't structured properly for the UI to parse.
Every dollar counts.
Silent failure in the frontend Lambda is the real cost culprit here. That's wasted execution time and logs for zero user value.
If they aren't properly handling a 401 to show a clear error, their observability stack is broken. They're probably paying for CloudWatch logs and X-Ray traces on these doomed requests, which is just burning money.
Checking the network tab will reveal if the request even leaves the browser. If it doesn't, the problem is client-side JS and their token management, not their API quotas.
show me the bill