Where is this? I’m on version 30 and looking at API tab in editor I see nothing for this
General settings
1 Like
This actually happened to me.
Someone took my postmark server API token, and sent 3000 emails through my server. It was spam emails.
As more apps are built with no-code tools, I think there’s a real risk that malicious actors will start actively scanning these platforms for exposed API keys and tokens.
I know not many will see this, but if you see it, go through and check your API calls, what about that call you set up 2 years ago when you were starting out?
A bunch of my API calls I created on the API connector to tie into my CRM have suddenly stopped working. I got with the CRM support and they confirmed no changes on their end. They’re working on Postman.
But in my app, the POST & PUT calls are broken, even when simplified down to a POST to Create a contact with only an email.
Reinitializing I am getting 400 errors for my POSTs and 500s for my PUTs.
Any idea why this could be? I wonder if it is related to this quiet update!
Unrelated, as the update only affects the response schema and only for newly initialised calls
1 Like
@georgecollier
ok, well the existing calls stopped working, and now will not re-initialize without getting the errors. Other calls under the same endpoint are working.
Can you expand on how the update affects the response schema?
Since I’ve verified that the GET & DELETE calls under the same endpoints are working perfectly, I wonder if it could be related.
It only effects the response of a call (i.e what you receive back after making a call), and only the schema of that (the basic framework/skeleton that Bubble creates for you to use), it doesn’t effect the actual making of the call at all nor does this change apply to existing initialized calls.
Bubble used to save the actual values you passed in when first initializing a call, but now no longer save the values only the ‘type’ of that property (i.e ‘string’, ‘integer’ etc)
@J805 I found out the exact same way 
Were these calls relying on dynamic values in the parameters or were they set to just use the same values as entered during initialization?
I saw somebody else experiencing a issue soon after this update where the initialized values as the defaults were not being used or something like that.
1 Like
Both.
When the calls are used in workflows in my original set up, which uses dynamic values, error was returned.
When I went in to the API connector to test (where I put in the coded values only), same error and would not reinitialize.
Interestingly, my GET and DELETE calls are working under the same endpoint. And, we tested in Postman and all the calls work there, POST, PUT, GET and DELETE all returning expected values, but those are obviously hardcoded initial values.
I am still stuck here unfortunately. If you see anything about this in the forums can you please tag me?
I had to remove my APIs from several dozen workflows in my App just to make it usable and have to do manual data syncs until this gets squared away. Any and all insights are greatly appreciated!
@andrew13 thank you for that context. It is the returned values that are the problem, it is returning an error. either 400 or 500, and I am guessing this is related to the structuring of the data.
Can you please direct me to more info on this update / where in the docs you found this info?
Without a single bit of context about what API or how you have set it up it’s going to be hard for anyone to give you any meaningful advice 
a 400 error is usually a ‘you’ problem (bad call set up) and a 500 is usually a ‘them’ problem (their server is having an issue).
Perhaps starting again from scratch on just one of the calls and seeing if you can nut out what the issue is in the setup there?
You can always reach out directly to Bubble support via email to see if they have any advice for you.
FYI, Bubble now obfuscates response data and doesn’t include it in client side code.
So, this part is no longer relevant:
2 Likes