Need to handle GZIP (Accept-encoding... GZIP) in API


I have an API that requires the request to accept gzipped encoding.

I played around with headers (such as accept-encoding: gzip, deflate; etc.) - no luck (just really long hang times).

Any way to do this?


1 Like


Did you get things to work in postman?

1 Like



So can you share a screenshot and your settings in Bubble?.. That’s how to do it, you replicated in the API connector what you have in Postman.

Postman handles GZIP encoding, Bubble doesn’t or doesn’t seem to - this is what I want to know from you… Does Bubble handle GZIP encoding or not? If not, can you enable it? If not, is there a workaround?

No ability to post a screenshot just now but no point - all I get from Bubble is error message saying data is Gzipped. Can follow up later with a screenshot if you still think it’s important.


Do you have a link to the doc of the API?

The documentation is in my account (not documented outside the account), so I’ll just share what it says, it’s extremely simple.

It reads:

"CSV or JSON from the last run

Use the following RESTful API to download data from your last successful Extractor run in CSV or JSON format. Please do not share your API key with anyone."

That’s it - you get an API address ([long code for this particular extractor]/json/latest?_apikey=[enter key] and you’re done. [Note: if you want a CSV download instead of JSON data you just change the ‘json’ in the API to ‘csv’. I’d like the JSON]

I’ve successfully used this in Postman and another platform ( Both Postman and have Accept-encoding: gzip enabled so it was easy to get it working. I have not been able to get it working in Bubble.

Anyway, hope this helps? Let me know if you need anything else to investigate this.


And can you share a link to your app with some credentials to test? It’s likely a feature request, not a bug, so we can’t guarantee we can add it.

@emmanuel seems like you never got a link on this question. I have the same problem with It runs in Postman but bubble gives me error.

Here is a link:

Any suggestions?

I solved it by using different product:’s “Magic” which doesn’t seem to require gzip or at least it worked there.

just wanted to check if this was resolved?

I am using API calls via a plug-in in Bubble to connect to our own system. The integration broke a few days ago and I have traced it to a change in the way the API sends responses. A change was made to the API where the response JSON is gzip compressed. Now in Bubble I get an error like this:


What caused me a bit of confusion initially was that the first thing I did was check Postman, but it turns out that Postman transparently unzips the compressed response.

Is there anything I can do or set in Bubble so that the API calls can work with the compressed response?

further to my last post here are the screenshots from Postman, showing a nicely formatted JSON response and the headers of the response indicating the gzip compression.

Same issue here and with another recent poster API response in gzip format

I have an API which is encoded in gzip which Bubble does not support. Postman will show the content just fine with Content-Ending as gzip.

@emmanuel Can we request gzip support in the API Connector data types

If anybody, is still looking for the possible solution to bubble limitation. I will share a solution for this.

  1. Instead of creating API call in a plugin, an action inside the plugin can be created

  1. Make sure that you set the Action Type as “Server side”

  2. Add the following code inside the code section

    function(properties, context) {
       const options = {
         uri: ‘’,
         gzip: true, // !! This is important needed for unzipping !!
         method: ‘GET’, // or POST, depending on the needs
         headers: {
         body: ‘’ // if POST is used
       response = context.request(options)
       if (response.statusCode == 200) {
         json = JSON.parse(response.body)
         return {
             your_property1: json.<fieldName1> , your_property2: json.<fieldName2>
       // if you want to return http error code and message as property values. For this you need to define this properties in return values section
       return {http_status_code: response.statusCode, http_error_message: response.body}
  3. You include the plugin in your application. Then you can add the action anywhere with plugins->

  4. The result of the action with the all the result properties <your_property1>,<your_property2>, etc is available for the next actions with “Result of step n”.

Forgot to say that you can get and use the API call parameters from the UI when you are describing the properties in the “Fields” part of “Plugin action”

P.S. I think that this approach is pretty much similar what bubble does with API Connections in plugin builder. If it is true, I wonder why bubble does not support gzipped results.

Hey Serg,

Thank you for sharing your solution to this gzip decompressing issue. I really hope @emmanuel and the Bubble team can quickly create a solution for this (seems like a relatively straightforward update for them to add gzip support to their api connection plugin, but I could be wrong).

I tried using your code to create a gzip solution of my own. I’m still getting an error thrown however.

Would you mind taking a look to see if there’s any error in my code. It looks fine to me as far as what I can tell.

function (properties, context) {
  const options = {
     uri: "{PROJECT_TOKEN}/last_ready_run/data?api_key={API_KEY}&format=json",
     gzip: true,
     method: "GET",
     headers: {},
     body: ""

   response = context.request(options);

   if (response.statusCode == 200) {
      json = JSON.parse(response.body);

    return { strains: json.strain };
  // if you want to return http error code and message as property values. For this you need to define this properties in return values section
  return {
    http_status_code: response.statusCode,
    http_error_message: response.body

Big thanks,

Hi Jaime,

  1. I see that you don’t defined return values. The return value name will be strains
  2. you can remove the body: “” line because it is not needed for GET request and can be the cause of the error. Don’t forget to remove the comma after headers line if you will return the body

If these steps will not solve your problem, just debug the logic with putting console.log(’…’)-s to see what and where things fail. You will see the log messages in the logs of the application which is using the plugin. Make sure that will use the latest version of the plugin with the application.

Important! Please remove the sceenshot from your post because it leaks some info that people should not see

Hey Serg,

I think I am throwing a return value (see line 15). I wrote “return { strains: json.strain };”

Is that not correct? Let me know if I need to maybe move the return statement somewhere else.

That’s odd, looks like the forum didn’t update my photo hiding my api key. Thanks for the catch there! (don’t want that info leaking out :grimacing:)

For sure, great idea with using console.log to debug the logic. It’s been a while evidently since I’ve coded in JavaScript. Your help is much appreciated :pray:

What I meant was to add strains in return values section as seen in the screenshot


Please add http_status_code, http_error_message as well. At the moment I cannot verify whether the absence will cause an error or not, but without them you won’t be able to access the values after the plugin action is finished

We’re going to work on this next week