I encountered this problem today. It was working since last year, then started to throw error like
[400] Error connecting to the API
(https://na2.docusign.net/restapi/v2/accounts/f0332a4a-528a-4f7f-a506-f1a9be016ca1/envelopes)"
When I test the integration in dev mode. It works just fine. I think the api endpoint has a problem. This endpoint https://demo.docusign.net/restapi for demo works flawlessly.
The base URL could also be the problem. Is anybody from DocuSign team able to verify this? I can't seem to find the reason why. I tried to regenerate token and use it but no joy. Again it works fine in demo but not on any production baseUrl.
The code is written in PHP and I'm using the PHP sdk version of the docusign.
Related
I am trying to setup a WhatsApp bot using voiceflow, based on the tutorial found here. I've set this up before and everything has worked fine, but now I can't seem to configure the webhook.
The steps I'm performing are as follows:
Clone the repo here
Checked ngrok is installed (version 3.0.7), and its location (/usr/local/bin/ngrok)
Created a .env file at the root with the VERIFY_TOKEN, PORT, and WHATSAPP_TOKEN
Started the app from root with npm start
Started ngrok with ngrok http 8000 (the same port as specified in my .env)
Checked the resulting address works in the browser
According to the documentation, I then configure the webhook by adding "/webhook" to the end of the URL, and adding the same VERIFY_TOKEN as specified in my .env file. This, however, gives me the following error:
The callback URL or verify token couldn't be validated.
Please verify the provided information or try again later.
I've had a look around at similar questions here, but could not find what was wrong. I have also spoken to others who encountered similar issues over the last few weeks. This process was working up until recently (Nov 2022).
The error msg: The callback URL or verify token couldn't be validated. Please verify the provided information or try again later. usually means you are not returning a 200 response to the webhook origin. I would make sure your code is returning a 200 to whatsapp.
As an alternative, try to set the webhook on glitch as explained here:
https://developers.facebook.com/docs/whatsapp/sample-app-endpoints#cloud-api-sample-app-endpoint
so that you can check if your meta account is valid.
From what I have found it seems that feature is now behind a paywall. It worked fine a few months ago on the free tier of ngrok. So you will need to upgrade your ngrok subscription for WhatsApp to start validating. You can read about it here. Try using Cloudflare tunnel.
I am randomly getting a login prompt asking me to log in to localhost:3000 while working on my project (in localhost). Sometimes it does not show up the whole day and next morning I get 10 prompts in a row (canceling through pressing escape), and then it starts working properly again.
These are the errors I get in the console when it has been canceled:
I suspect one of the following, but really I have no idea:
Webpack is not configured correctly
There is some resource that requires authentication (but I can't figure out which), I am running everything on localhost
There is something wrong with the node.js server thingy...
Any tips on what might be going on are very welcome.
Edit: My backend is mocked in localhost.
Edit 2: I found this: Receiving login prompt using integrated windows authentication and it is possible that the thing that is causing the error is some faulty configuration in my IIS. But it is difficult to verify since it only shows up randomly.
Webpack has nothing to do with your API calls.
401 errors are due to auth credentials failing.
It means that your backend ask you to update your token(s) used for auth in API calls.
I have a weird situation going on, I always get a 401 invalid_client error when trying to make a payment on my production system using the node SDK.
The credentials are a 100% correct, mode property is set to live and this config works on localhost - I can process the payment with no issues. So sandbox works on production and localhost, live works only on localhost. ENV variables are exactly the same when I simulate live mode on localhost. The debug id I get from PayPal is bc930e48644c9. Does anyone have a clue what is going on here?
Issue already set:
https://github.com/paypal/PayPal-node-SDK/issues/320
Seems to occur after the v1.8.0 update of the node sdk. According to the description a rollback of the npm package to v1.7.1 seems to work.
EDIT: Just confirmed that by my self. Works.
My code runing test url is perfect working but when i run code in server https://secure.payu.in/_payment and key and slat key is not working
Please help me anyone
I was also facing the same problem but I have figured it out. It's just your merchant ID has not been verified yet so it will be redirecting to the test server even though you have passed https://secure.payu.in/_payment in the payu_base_url. Thanks
I'm trying to use the web api to query a user's playlists (using the spotipy Python library). I got the user to oAuth in, got an access token, made the request and got a 500 error:
SpotifyException: http status: 500, code:-1 - https://api.spotify.com/v1/users/125139403/playlists?limit=50&offset=0: Server error.
I then tried the same request in Web API test console and it worked fine.
But then things get kind of weird. I tried running the cURL command the console generated in a terminal and got the same 500 error.
Then I tried running the same request using cURL but just changing the username in the URL and it worked fine (at least for public playlists) for both my username and a random friend's user ID number.
I thought maybe I'm having a token issue but the token I'm using seems to work fine with other usernames. It's just the one specific user for whom I'm getting the error.
I'd rather not post the user's ID on this public forum but I can email it to someone if it's relevant.
My best guess for what's wrong at this point is a bug on Spotify's side but I certainly could be doing something wrong.
Again, thanks for reporting this. This bug was fixed by Matt M. and was just deployed to production.
Please try it out in our API Console. (which Matt was also part of building!)