Forum Academy Marketplace Showcase Pricing Features

Bubble API connector - Processing HTTP Error / Status Codes

The bubble API connector is great for “Sunny” day cenarios. It can connect to just about any external service.

Now, I’m now running into some limitations with “Rainy” day scenarios.

Continuing the discussion from [Feature Request] Error in Logs, or let us manage errors responses:

Like the post above, I want to able to write some logic and workflows based on the HTTP error codes returned.

In the example, above I want to ask the user to enter the address again if I get an HTTP error code 422, and so on.

Has anyone found a way to do this - process the error code from the bubble API connector?

@emmanuel - Is there any workaround we can use? If not, is this on the product roadmap? Ability to handle “Rainy” day scenarios - as the complexity and maturity of bubble applications increases, this need also increases.

4 Likes

No immediate plan, but we’ll think about it. I think a few other things regarding the API connector will come first (like Oauth, if possible), but eventually we should have an answer there as well. I can’t commit on a timeline though.

Agree. OAuth would be a very welcome feature indeed !.

On this topic, and without knowing how bubble platform is set up - is there a possibility to expand

to cover the use case I’m describing?

Not immediately, it’s a very different part of code. We’ll think about it though.

Any update on this? I noticed that using SendGrid from the API Connector, there is currently no way to store the Status Code value (i.e. there is no way to determine if the email was actually accepted by sendgrid).

Is there any solution to this in the meantime? For booking platforms, this is critical.

I have to follow-up on this @emmanuel I have a plugin for a customer that is impossible to know in the editor that an error has been encountered. In the logs it clearly shows Raw error but in the workflows there is no way to test this against.

Exposing the status codes will be extremely beneficial to everyone.

1 Like

+1 on this, very crucial!!

+1 for api connector status code access. My use case is to process information from Clearbit. Status code is the only way to know if a second attempt to pull data should be performed…and since the fee for the service is per api request, I’d prefer not to double up.

RESPONSE TYPES
Code Description
200 Successful lookup, person encoded in the response body.
202 Asynchronously looking up the person.
404 Person not found.

EDIT: Clearbit actually allows for a webhook, so there is a way around this for me.

Yes please. Come on Bubble team do your magic!!!

1 Like

there has been an update on this topic?

1 Like

It is pretty standard in REST API design that 400 codes are valid responses (e.g. not found). Not being able to handle these responses properly is a pretty significant design flaw in the API Connector.

As a workaround I wrote a simple Azure Function (node.js) to wrap API calls and always return 200 with the actual code in the response body. Seems to solve the issue. Bubble could easily implement something like this this.

Here is the Azure function code in case anyone else is blocked by this as well. Just call the Azure function http endpoint with the path /bubble/your_api_path.

index.js:

const BASE_URL = '<YOUR API BASE URL>';
module.exports = async (context) => {
    
    //create a response conforming to JSend format - https://github.com/omniti-labs/jsend
    const respond = (code, message, data) => {
        context.res = { 
            headers: { 'Content-Type': 'application/json' },
            status: 200, 
            body: {
                code: code, 
                status: (code < 400) ? 'success' : (code < 500) ? 'fail' : 'error', 
                message: message, 
                data: data
            }
        };     
    }

    const options = {
        method: context.req.method,
        uri: BASE_URL + context.req.params.segments,
        headers: {
            'content-type': 'application/json',
            'x-authapi-client': context.req.headers['x-authapi-client']   <--THIS IS SPECIFIC TO MY API
        },
        qs: context.req.query,
        body: context.req.body,
        json: true,
        resolveWithFullResponse: true,
        simple: false
    }
    const request = require('request-promise-native');
    try {
        const response = await request(options); 
        //NOTE: change the respond params based on your API response format
        respond(response.statusCode, response.body.message, response.body.data); 
    } catch (e) {
        let msg = ('message' in e) ? e.message : ('cause' in e) ? e.cause : 'unknown';
        respond(500, msg, null);
    }    
}

function.json:

{
  "bindings": [{
    "authLevel"   : "anonymous",
    "type"        : "httpTrigger",
    "direction"   : "in",
    "name"        : "req",
    "route"       : "bubble/{*segments}"
  }, {
    "type"      : "http",
    "direction" : "out",
    "name"      : "res"
  }]
}

host.json:

{
    "version": "2.0",
     "extensions": {
         "http": {
             "routePrefix": ""
         }    
    }
}
1 Like

Any update on this? It limits what you can do with the API connector without capturing the error codes

1 Like

Has anyone found a way to capture error codes?

1 Like

Except by creating own plugin (and not use the API connector), for now it doesn’t seem that there’s a workaround with API connector.

1 Like

Another +1 on this. I need this too.

Another +1. We just built our first app with Bubble and ran into this. API connector is awesome except for this major gap.

I see that it is impossible to process error codes, but is it possible to process errors at all?
I’m putting some data retrieved from API call into a text element. If the API call returns an error, the text element content is left empty. I want to use a condition that “if API call returns any error, put error in text element content”. Is it possible to do in Bubble?

If this were a thing it would be extremely helpful!

Hi all!
This issue is already very old. Are there any plans now to implement this additional feature? It’d be very helpful (not to say crucial) for many Bubble apps. :thinking:
@emmanuel @allenyang

2 Likes

Any update on this? I have a GET API CALL that needs to validate if an email has been already in use with the API provider.

Thanks in advance…