Does anyone know how to change an equity order utilizing the etrade API? I can do place order just fine but for some reason changing an equity order seems impossible! I have poured over the documentation and have failed at understanding how to do it.... I keep on getting a 9999 error
https://apisb.etrade.com/docs/api/order/api-order-v1.html#/definition/orderPreview
I couldn't get it to work either. I printed the errors and reason codes
https://api.etrade.com/v1/accounts/{myaccountkey}/orders/76/change/preview
<Response [405]>
Method Not Allowed
<Error>
<code>9999</code>
</Error>
405 isn't documented, and 9999 says The service you requested is not available at this time. Please try again.
Probably best to cancel and reenter the order, unfortunately.
Related
I am using CE 10.4 and this example from Stephen Ball:
https://github.com/DelphiABall/Azure-Cognitive-Services
From that example, I tried "Speech Service" and always get a 401:
Access denied due to invalid subscription key or wrong API endpoint. Make sure to provide a valid key for an active subscription and use a correct regional API endpoint for your resource.
Fiddler shows, that subscription-key is sent in the Body, not Header.
My Key works in other Application.
As the Code is published from an official Embarcadero Representative, I assume, the Code is right.
Can anybody confirm this behavior - and/or knows, how to change the Code?
Ciao Luigi
In the meantine, the issue is fixed.
Stephen updated the repository.
In one of my self-asserted technical profiles, I use a validation technical profile which calls a REST service. That service returns a 200 or 409 if all goes well, but it can also return a 500.
If that happens, the following message is shown:
I'm looking for a way to translate that message.
It's not using DefaultUserMessageIfRequestFailed and I can't seem to find it in the default page level resources file either.
The docs also don't seem to specify anything concrete enough.
I'm assuming it's some kind of default message for when an orchestration step fails, or when any claims exchange fails, but I can't seem to find any details.
Any pointers?
Microsoft is fixing the behavior for error code handling from rest apis. the recent changes you see here are a result of that.
The bug fix for issue you are seeing will be rolled out in next 2-3 weeks. And then you should be able to use DefaultUserMessageIfRequestFailed or potentially some other metadata element to control this error message.
I try the following request to get 8 latest post results from my Instagram account but, despite of I am using count=8 but, Instagram still provides only 5 results.
https://api.instagram.com/v1/users/self/media/recent?count=8&access_token=
But, when I use count=15 it provides 12 results! Where could be the problem? Any thought?
Thank you.
I'm trying to follow the instructions at https://developer.paypal.com/docs/classic/mass-pay/integration-guide/MassPayUsingAPI/#id101DEJ0100A for paying a customer. https://www.paypal.com/us/cgi-bin/webscr?cmd=_profile-api-signature# tells me the API username, API password and and signature. I paste those values directly into my program, and POST those parameters (as well as other parameters) to https ://api-3t.paypal.com/nvp and I get this response back:
TIMESTAMP=2015%2d05%2d06T23%3a58%3a01Z&CORRELATIONID=6eef131f4a296&ACK=Failure&VERSION=2%2e3&BUILD=16566018&L_ERRORCODE0=10002&L_SHORTMESSAGE0=Security%20error&L_LONGMESSAGE0=Security%20header%20is%20not%20valid&L_SEVERITYCODE0=Error
Any tips for troubleshooting what might be going on here?
Thanks in advance!
Kevin
That error means the API credentials you're using are not accurate. Double the check the values themselves and make sure you didn't miss any characters or add any extra white space on the ends of the values. Also, make sure you're not sending sandbox credentials to the live PayPal server or vice-verse. That's usually what's happening when people run into this.
I have set up mozpay in my app. When I send the signed jwt with the post-back URL to the app, and then the app uses it with mozpay, during simulation, the post-back URL gets hit 6 times. I wanted to know if that's intended. If so i can work around it, but if its not intended i would rather fix that problem.
Is it possible that the 6 post-backs only occur during simulation?
Also is this any different in the charge-back URL?
Is there a setting that I can set in the signed jwt to change this?
If there is some documentation on this, I haven't been able to find it, and I would greatly appreciate a link.
What you describe is expected behavior. Since your postback URL was not responding correctly, Mozilla's server retried the post 5 additional times before giving up. As you mention, when you fixed the transaction response you no longer saw so many requests.
There was an answer here, but I dont see it anymore. The answer was fairly correct.
We were sending back "webpay: {transactionID}" what we didnt realize is that {transactionID} includes the text "webpay:" So all we had to do was send back "{transactionID}" instead.
I would set as the answer the person who posted, but i no longer see the post. Thanks.