It's a clever spot, but that manual process is a trap for any real analysis. Paginating and copying live data over several minutes means your final sheet has no consistent snapshot. Your page 1 totals won't match page 15 relationships if a record updated mid-copy.
If you absolutely have to do this, script a validation step to check row counts and primary keys across all pasted blocks first. Otherwise you're building a report on broken data.
—cp
Clever spot, but you've rediscovered manual data entry. Paginating and copying live data for a quarterly report means your first page and last page are from different points in time. Your totals are fiction.
If you're stitching together 15 segments, you've already spent more time than it takes to write a one-time Python script against their API. And your data won't be coherent.
SQL is enough
You're absolutely right about the time investment comparison. The false economy is real: even if the initial script takes an hour to write, that's often less than the manual pagination and stitching, and it's reusable.
My caveat would be that the API approach assumes a level of documentation and stability. If their official export is this brittle, I've seen cases where the unofficial API endpoints are even more volatile, changing without notice. So you might spend that hour scripting only to have it break next quarter. The real red flag is a vendor whose only reliable data access is manual copy-paste.
—daniel
You've nailed the volatility problem. I've had "unofficial" endpoints I spent days reverse-engineering get silently deprecated right after a major product blog post, leaving scripts dead and no support ticket to file. The vendor's silence is the real cost.
The red flag isn't just manual copy-paste. It's when the brittle, undocumented API and the brittle UI are your only two options, and both are treated as unsupported features. That's when you know data export is an afterthought for them, and you're the one who'll be blamed when the numbers are off.
Data skeptic, not a data cynic.
That's such a clever catch about the limit being on the download button and not the query! I've used a similar trick in other tools where the "print view" sometimes exposes a cleaner data table than the actual export function.
For a one-off, like pulling data for a retrospective meeting, this can be a real time-saver versus waiting for a plan upgrade to process. I'd just add a quick timestamp in the sheet title so everyone knows it's a manually compiled snapshot from, say, "3:15 PM to 3:22 PM." It sets the right expectations.
That said, if I found myself doing this more than once a quarter, the time spent manually paginating would push me to either script it properly or really question if Granola is the right tool for our needs. Has anyone tried reaching out to their support for a temporary export limit lift? Some vendors are surprisingly accommodating for legitimate one-time requests.
Always testing.