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
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.
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.
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’
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.
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:
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
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.
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
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…)
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.
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.
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.