New API connections

I don’t believe it is necessary…I have never needed to use that before, and I have an API to another one of my Bubble apps that is working with the same setup as the ones that are not…the only differences that I can tell are that the ones not working, the apps providing the api are enabling the api while the ones that work the api has been enabled for a few weeks.

This is an api call in the same app I’m trying to set up the others in…the app providing the api had the api enabled a few weeks ago and it works fine

Trying the suggestion like this

results in the same 404 error.

Seems like the error is saying the API URL doesn’t exist, so my assumption is something is wrong on the Bubble side of things in the way the enable api is functioning at the moment.

1 Like

Ah, interesting. :thinking:

Looking through some of my older apps, I seem to always have used the method I mentioned above. I forgot to mention that the Authentication type is Private key in header.

Trying your way resulted in the same error. But this seemed to also have worked, and came from the reference manual. This is using the Authentication method of None or self-handled.

https://yourappname.bubbleapps.io/version-test/api/1.1/obj/something?api_token=[API Token]

Still would be curious on the bug you’ve reported though.

Are you saying you tried that and it worked?

I just tried it and I get the 404 error still. I also tried the private key in header and get the same 404 error.

Also, I read through the reference, could you share the link where you found that? I have a hard time finding things with the new ‘manual/reference combo’

Yes, working for me. Here’s the reference:

What happens when you use an external tool like postman?

Thanks for the link…I had seen this in the past and it seems more complete than what I found going through the new reference.

I found this section from the link you provided describing error codes

So it seems to validate my thought there is a bug with Bubble in how they are creating API endpoints at the moment.

All the apps that had the api enabled in the past work…but trying to create a new api endpoint in an app currently is not working; the setup is showing the URL and everything, but consistently getting the 404 errors.

I submitted a bug report to bubble so hopefully support will be able to provide some insight into the issue.

Thanks for your help.

1 Like

I’ve never used Postman or an other external tools…just setting up the calls in the api connector plugin.

One last thought to try… is empty cache and hard reload on the editor page. Not sure what browser/OS you’re running or if it’ll make a difference.

Chrome for example:

Click and hold the refresh button, then choose the last option. Then try the api call again.

image

When you get a 404 it has nothing to do with the token. Even with a wrong token and wrong placement, you should get a 200 with an empty response object as long as the endpoint is correct:

"response": {
    "cursor": 0,
    "results": [],
    "remaining": 0,
    "count": 0
}

My guess is that the change has something to do with the changes to the free plan as api access is not included anymore: http://forum.bubble.io/t/changes-to-our-free-plan/138385 (see first post by Emmanuel)

Ok. The main reason for asking is that troubleshooting is usually much easier with a tool like postman. So a quick tip from here is to use learn basic postman if your apps needs access to external apis :slight_smile:

As per my other post, I think api access is unavailable because the apps you are trying to connect to are free tier. The ones where the api works had api access activated before the change in plans.

You should get a 500 in that case.

Actually I find Postman way too complex for basic troubleshooting now.

Hoppscotch.com is a nice alternative.

I think I had this recently. An endpoint that had existed for a year suddenly went 404 in Dev.

No, 4xx is client side errors and 404 specifically is by most standards used as a"not found" response. 5xx on the other hand are server-side errors, e.g. when the code breaks down.

Just tried with a free tier app of mine and I get a 404 when I try to enable data api whereas another free tier app where data api was already enabled works as expected.

I actually tried and did like hoppscotch.com before when it was called postwoman, so that is definitely a good alternative! Just have too many things in postman already, so that is a go-to tool for me :slight_smile:

Hmm, strange. Just tried with another app where I get this as a 401 error:

"error_class": "Unauthorized",
"args": {
    "code": "...x503548190186746700"
},
"message": null,
"translation": "This application does not expose an API. Please upgrade your Bubble subscription for your API calls to run."

But looking at op’s get request it also seems it is malformed. It ends with
“/api/1.1/restaurant” but should be “/api/1.1/obj/restaurant”.

@boston85719 try adding “obj” before your object type in the url. And be aware that your items as of now is public (e.g. you have not set any privacy controls, so I can fetch them even without using your token…)

I’m actually having problems with apps on template and instructor plans…both of which should provide access to the api


Understandable that the free plan doesn’t allow for it…they should definitely consider putting some sort of notification on the api section of the settings, rather than just on the plan type area; a UX that would provide a popup that notifies users on free plans that the api can not be exposed when they go to check the box to expose it, rather than make it seem like it is set up properly.

Must be in the attempt to make the changes, they also changed the template and the instructor plan as well.

My mistake. I would not expect 200 where it is not authorized.

Yes! That fixed it up on the template and trainer applications. Great eye…I wasn’t paying that close attention and thought the ‘obj’ was the data-type name and would replace obj with data-type name.

2 Likes

I tend to agree. My guess would be that the privacy features of bubble would make it impractical to implement a 401 response at the “API Gateway” level as dynamically as builders need it, so its done at the database level instead, thus the code simply returns empty objects if there is no token.

This topic was automatically closed after 14 days. New replies are no longer allowed.