https://discord.gg/botpress logo
Join Discord
Powered by
Should calls to external api’s work when testing b...
# 🤝help
r
I’m trying to call the pushover api from an execute code node. When I test my bot in the emulator, it always returns 404. Is this supposed to work - or intentionally blocked? Any workaround? The URL is https://api.pushover.net/1/messages.json
f
Hey @rapid-manchester-41665 can you share how you're calling the API?
r
@User Sure. Here’s the code from my execute code block: const pushoverApiUrl = "https://api.pushover.net/1/messages.json"; const pushoverToken = env.stumpyPushover; const pushoverUser = env.pushoverUser; const message = workflow.messageToOwner; const payload = { token: pushoverToken, user: pushoverUser, message: message, }; try { const response = await axios.post(pushoverApiUrl, payload); console.log("Response from Pushover API:", response.data); workflow.nextCard = "Success" } catch (error) { console.error("Error while calling Pushover API:", error.message); workflow.nextCard = "Failure" }
This code works perfectly after the bot has been published. But it generates a 404 when I am trying to test in the emulator. (I initially thought that maybe all external calls were blocked from the emulator - but my sendgrid api calls work fine.)
e
I have a Zapier API which takes unanswered questions and sends to a google sheet, it works in the emulator.
r
@eager-australia-26534 Yep - I’ve also tested a Zapier call in the emulator and it works for me too. However, the call to the Pushover API does not work from the emulator yet it does work after being published and run in a web browser (which proves there is nothing wrong with the URL I’m using). Maybe it needs to be whitelisted in the emulators web proxy or dns ? 🤷🏻‍♂️
e
Hey @User I think what's happening is that your env variables on development are incorrect, can you double check them?

https://cdn.discordapp.com/attachments/1132038190757322864/1132400850745184426/image.png▾

r
@early-train-33247 Is there a different spot to put them for development? I only have them in one spot - and as I said, it works (without changing anything) if I publish the bot and test it using the “Share Bot” link. They’re configured under “Chatbot Settings”->”Configuration Variables” and they do resolve properly.
Ok - so I didn’t realize there were different places to set the configuration variables - but I just found the doc that describes this. That makes my problem even more perplexing since I have no values set for production. I only have the development values set - yet my API key is working via the “Share Chatbot” link but NOT via the emulator.
e
This might be happening because the API doesn't require a token and a user, and when you don't provide any it works, but when you do, you use invalid values. Can you try confirming if that's the case?
The Shared Bot used the production variables, which you can define through the dashboard
r
I’m sorry - I can’t tell if you’re another user trying to help me - or if you’re with BotPress…. But I’ve now got 2 API calls in my flow (and they both definitely need API keys to work). One is to Pushover and the other is to Sendgrid. From inside the emulator, the pushover one fails and the sendgrid one works. If I publish the bot, they both work.
e
I'm part of the team 😉
r
Does the emulator run on a different virtual server than the production code? Can I get someone to try to ping api.pushover.net from both servers and verify that they both return valid IP addresses???
e
What do you mean by not working? What is the error message you get?
r
404 - server not found
e
That's odd! Are you sure the URL has to include the .json file?
r
16:16:20errorError while calling Pushover API: Request failed with status code 404
I’m sure that it works in one environment but not in the other - and the only difference is emulator vs non-emulator. Everything else is identical. Same API keys, user secrets, etc…
And 404 means “not found” right? If it was a key problem, it would say “not authorized” or something else.
e
Hey I found out that when you don't define a variable in the Dashboard, the bot used the develoment one (from the Chatbot settings)
So your shared bot is using these variables here

https://cdn.discordapp.com/attachments/1132038190757322864/1132768980478726217/image.png▾

r
Ahh… that makes sense. But it’s defined in both places now - thanks.
e
Yes, it couldn't find the server
r
Right. So it must be a DNS problem or a web proxy, right?
e
It's possible, we have had problems with that recently. If you don't mind, I am gonna request support from @witty-football-93730, because he knows more about this area and the recent problems!
r
I don’t mind at all. Thanks for your help. If there’s anything I can do to help get this fixed sooner, please let me know…
e
Alright! I'm reading the Pushover documentation and it seems that the token, user and message info should be passed as a URL param, or as a form encoded value. Are you aware of this?
You could try adding headers to your request: 
await axios.post(url, payload, {headers: { "Content-type": "application/x-www-form-urlencoded" }})
, but you need to encode the payload
r
“Could” or “Should”? The code I have now works fine in production and I don’t really see how adding headers to the api call will help with a 404?
e
I'm not familiar with the API so I can't give you a definitive response on how the request should be formatted
but yeah there seems to be a difference of how axios requests work in development and production that might be causing these issues.
r
I thought it was less secure to include the api-key as part of the url.
e
And regarding the 404 error, it could be a bug from the API, since the URL is correct. It might be returning a 404 not found when the actual response should be 400 - bad request (invalid data)
Sure, the right way is the way you are doing right now - including the data in the body
r
I’m not at all familiar with axios - but I’ve just gotta keep re-iterating that the exact same code and axios call works after I publish the bot. That kind of rules out any problem with the code of structure of the API call…
e
In short - your code is right, Let's see what @witty-football-93730 has to say about this dev/prod inconsistency!
He shall come back online tomorrow!
r
Alright. My money is on name resolution - but we’ll see! 😆
Thanks again for your help.
e
Anytime, sorry I couldn't get to the bottom of it!
r
No problem. As long as it’s being pursued and I don’t have to live with this forever… 🤷🏻‍♂️
w
Hey @rapid-manchester-41665 I'm catching up on the support here. I've seed this before but it has been resolved. Do you mind trying to hardcode your env variables just to remove remove this from the equation const pushoverToken = 'your token' const pushoverUser = 'your user' There's a possibility that the pushover api returns a 404 when you're providing wrong user or user groups, and I want to make sure that there's nothing wrong with it in case the config var doesn't get set properly
r
@User When the API key is incorrect, the pushover API returns: Actions Error while calling Pushover API: Request failed with status code 400
But I ran your test anyways and hard-coded the token values and I still get: 14:47:18errorError while calling Pushover API: Request failed with status code 404
w
I'm relatively clueless right now, I have 2 other issues to fix. I'll get back to you later today. It might be related to your authorization object (it might conflict our proxy)
r
@witty-football-93730 But it doesn’t conflict in production? Do you use a different proxy product for production? If not, then my code itself is not causing the problem. 🤷🏻‍♂️ Start by testing name resolution on the Proxy Machine - see if you can ping “api.pushover.net”. If that fails, check the dns server/hosts file and firewall. If it works, check the blacklist/whitelist on the proxy. 🤷🏻‍♂️
w
Well ok here is the backstory as you seem to be a relatively technicall user When you build your bot, it's your browser that executes your code (and pretty much anything else) in a safe way. The only issue is that when you are performing http calls to your server / 3rd party system (in this case pushover), your browser will most likely refuse to perform this request (CORS). To circumvent that, we proxy all of your http requests through a simple server of ours. In production, your code is executed on our servers in a micro vm, we don't have to proxy anything. This is why it works in prod. Back to the issue now, it seems like working fine for most users, it makes me think that there is some conflict between your auth body and ours (because our proxy is authenticated). I'm done with the 2 other issues, I'll check a little more .
r
@witty-football-93730 Thanks for the explanation - I assumed you were using a Cors proxy in both environments - but when you say “working fine for most users”, do you mean API’s in general - or specifically the Pushover API? (Because other API’s are working fine for me too - it’s only the Pushover one that appears to not even be able to reach the server). I’ve successfully consumed the API’s from Zapier, SendGrid, GoogleStaticMaps and imgBB - which is why I keep coming back to name resolution or firewall (on the server that your Cors proxy is hosted on - or the configuration of the Cors proxy itself or the firewall/gateway between that network and the internet).
w
@rapid-manchester-41665 I meant for other apis. Do you mind sharing me your bot id ? you can easily find it in the studio url

https://cdn.discordapp.com/attachments/1132038190757322864/1134483682749599794/Screenshot_2023-07-28_at_9.52.43_AM.png▾

r
@witty-football-93730 Sure, it’s: "botId": "b0b54374-5ead-46c0-bb6d-f547067ffbc3",
w
Can you also perform a few failing requests for me so I can check the logs of our proxy 🙂
r
Sure. I’ll republish it and make it fail twice. Standby.
Ok. I just generated 2 failures. The pushover api call fails, followed by a call to the sendgrid api that works.
w
I see 2 404s ... Both are requests to 
/api/proxy/YOUR_ZAPIER_URL_HERE
r
??? No. I tested with Zapier last week. It’s not being used anymore.
w
do you happen to have another execute code card that calls this ?

https://cdn.discordapp.com/attachments/1132038190757322864/1134486153882509382/Screenshot_2023-07-28_at_10.02.49_AM.png▾

r
Oh crap. Wait. Let me do it again with the longer flow. I tried to take a shortcut just now and used a short path to generate the error - but in it I had tried (unsuccessfully) to direct the api call to pushover via DNS alias I created in Cloudflare.
Just give me 2 min and I’ll do it again with the main flow.
Also - since I just woke up - I was trying to do this with the published flow (which would have worked). I need to do it from the emulator to generate the error you want. 🤦🏻‍♂️
Ok. Done.
I just did it once. Let me know if you need a second failure.
w
ok got them.
r
pi@piv4:~ $ curl https://api.pushover.net/1/messages.json -o pushover_reply.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 174 0 174 0 0 413 0 --:--:-- --:--:-- --:--:-- 413 pi@piv4:~ $ cat pushover_reply.txt {"secret":"invalid","errors":["secret must be supplied; did you mean to do a POST? see https://pushover.net/api"],"status":0,"request":"62887836-14e1-4083-a8fc-e2e91110e013" pi@piv4:~ $ If you run a simple curl to api.pushover.net/1/messages.json from the cors-anywhere server, you should get a response like this. But if you are not reaching the server (or reaching the wrong server), you’ll get something different - which may point us to the problem.
w
Hang on I'm getting somewhere.
I've got a meeting starging now I'll get back to you later. But I'm able to repro in a isolated dev environement. You can expect a fix or at least some explanation later.
r
Great. Thanks. I sure hope it’s a fix instead of an explanation… 🙂
w
I found the culprit, the lib we sure is adding a few headers, one of them is 
x-forwarded-host
for some reason if you call pushover reply a 404 whenever this header is present.
proof 🙂

https://cdn.discordapp.com/attachments/1132038190757322864/1134591979829866566/Screenshot_2023-07-28_at_5.02.04_PM.png▾

https://cdn.discordapp.com/attachments/1132038190757322864/1134591980148641824/Screenshot_2023-07-28_at_5.02.40_PM.png▾

r
The screenshot you show exhibits a 400 error - not the 404 error I’m receiving. Are you sure this is the culprit? Oh - or is this the response you get when you do NOT provide the header (because you don’t have an API key)? So where does this leave us? Can you suppress the header for calls to Pushover so that it works in the dev environment?
w
@rapid-manchester-41665 400 is what we want, when the header is disabled, 404 is what we're getting when the header is set (the second screenshot). I'm 100% sure this is the issue. I issued a fix on Friday, it's on its way to production. You should get it Today
g
@eager-australia-26534 do you mind letting me know how to create a zap like that?
e
if (workflow.ZapierMessage === "Sorry I do not have an answer to that question, if you would like to speak to a human, please say so.") { workflow.zapierSuccess = false let currentDateTime = new Date() const messageData = { property: 'Abdullah's House', date: currentDateTime, message: workflow.UserQuestion } // This adds to a zapier table or a google sheet of your choice. Setup in Zapier yourself and replace YOUR_ZAPIER_URL_HERE with your webhook URL. try { const response = await axios.post('YOUR_ZAPIER_URL_HERE ', messageData) console.log(response.data) workflow.zapierSuccess = true } catch (error) { console.error(error) } } //Use this code but replace everything with your own information, I'm hoping you understand what I'm saying, its pretty basic.
g
Thank you
e
Now create a zap using a zapier trigger and google sheet create row function within zapier, get your webhook url and put it in the code.
r
Thanks! I just confirmed that the fix in Development works! This makes my life a little easier.
14 Views
PreviousNext
Powered by