Issue on Grist .xlsx export via API

I cannot tell if the issue is on or Grist side so sharing here too an issue report which was just posted to

Expected behaviour
On the Grist module: should export a functional Excel file in .xlsx format via API same way as it exports the file via it’s native UI (see the attached PDF and files).

Current behaviour
Exports the file via API on the scenario OK but the file fails to open on Excel = file is somehow wrong/ broken?

Export of a simple table of data works ok when done via Grist UI.pdf (561.0 KB)

Excel samples (working and not working .xlsx exports)

I think @jarek looked into this - anything you can share on what you found @jarek?

It is pretty easy to check that the Grist API for Excel exports is working - this one:

Whatever make is doing, it presumably uses that endpoint. I’m not sure what Grist Labs can do to help with this? @Tomas_Westerholm if you can convince yourself independently that the Grist endpoint is working it might help you make a stronger argument to make that the problem is on their side?

Is there an API endpoint to pull ready .xlsx formatted blob? Yes there is. I will give it a try.

Content of document, as an Excel file


Here’s the test (still) using platform:

  1. pull the document via API:

  2. upload the document (blob) to Google Drive:

  3. opening that file still gives an error:

Could it be that the “Body” (blob) needs some conversion before saving to file?

It would be wise to just look at the output of Body directly, if you can, for example by working outside of make.

The URL in the screenshot looks to end in /download, which won’t give an Excel file. Try /download/xlsx.

For example, here is an example URL for a public document:

Ah, sure!

Now, the file size is smaller and the error message is different:

But unfort, clicking YES results in the terminal error seen before. So, not yet resolved.

Your example URL link works ok:

Same is true for our table.

But URL is different of what your example format is:

even the API guide suggests to use the client subdomain name in API call in diffirent, this way:

So, I will try to follow your URL, not the API guide.

Those URLs should be equivalent, for example for the public doc this URL also works:

Ok, by using that different URL (and set to public) it works. Next I need to test non public.

After setting it to non public, there is this error (understandably):


I think there is some difference in those two different API paths as they return different size data (blob). Your example (of the public URL) works ok but we cannot use public access in this use case. API handles the authentication but the API endpoint has “hardcoded” beginning part which I cannot overwrite thus not able to use the alternative URL path.

I should figure out the authentication using the general HTTP modules, I guess.

That’s strange. I’ll double check that case, of a private document accessed via the two variant URLs.

In the sample files you included at the start, one of them was reported as a truncated zip file (xlsx is a zip-based format).

Could it be that zipping is missing for the failing file?

A quick command line test seems to work fine. This gives a valid x.xlsx file for me:

curl -o x.xlsx -H "Authorization: Bearer XXXXXXXXXXXXXXXXX"

Can you check this for yourself?

1 Like

Yes, just worked out the same and it works now! Thanks a lot :+1:

What should we conclude here? The other API path / or Make implementation has an issue?

I’m glad something is working for you, but I’m not clear what you worked out and what works for you :slight_smile:

In my testing, I get valid files from either of the following:

curl -o x.xlsx -H "Authorization: Bearer XXXXXXXXXXXXXXXXX"
curl -o y.xlsx -H "Authorization: Bearer XXXXXXXXXXXXXXXXX"

Is there another URL variant to test? I’m not 100% clear on what is working for you and what isn’t.

Instead of using Grist module to do the API calls, I used native HTTP commands and just set there the Authorization manually and the URL of different format (not the one that Grist API guide suggests) but the one you pointed out.

API Guide: (not working for me)

Your URL version: (works good for me)

Ok, I will still need to test the other one with this native HTTP module. Moment…

1 Like