WebServicex Currency Convertor API is returning always -1 as the conversion rate regardless of the currencies I specify..
Is there a way I can get it to work, to return an actual accurate conversion rate please?
I don't know why minus 1 is returned. I think there are only 2 parameters FromCurrency and ToCurrency. Here's an example URL I used:
HTTP POST REQUEST:
httppost://www.webservicex.net/currencyconvertor.asmx/ConversionRate?FromCurrency=GBP&ToCurrency=EUR
Here is what's returned:
-1
I also tried From USD to EUR but it still returned -1.
Do I need to register and enter a developer key as a parameter or something? I didn't find that information anywhere, it's just a guess.
If nobody can help me with Webservicex; their service is not working properly; maybe it's just not a good one, can anybody recommend a good currency conversion web service. I want to call the result from within my db solution to meet my clients request, and I only have a day before I need to show something working to them. I hope you can help, it would be much appreciated.
Thankyou
Kind Regards
sharpie
You may use the yahoo finance api.
http://download.finance.yahoo.com/d/quotes.csv?s=GBPEUR=X&f=l1
Although it will give the csv but if you will just use it in script then it will give you the direct transaction value.
I hope it will serve your purpose.
Related
I'm trying to Put / Patch grants, but get an Ical exception. What is wrong with this:
BEGIN:VCALENDAR
PRODID:prodid
VERSION:2.0
BEGIN:VEVENT
DTEND;TZID=Europe/Amsterdam;VALUE=DATE:30001231
DTSTAMP:20221028T151844
DTSTART;TZID=Europe/Amsterdam;VALUE=DATE:20220824
SEQUENCE:0
UID:f03cdae7-8475-40b5-8521-c902d736e508
END:VEVENT
END:VCALENDAR
Regards,
The problem with your ICAL is the DTEND value with a year of '3000'.
You are right, this ICAL was accepted before, even though it was not supported. We changed this recently and missed that someone had this specified, for what we apologize, of course.
The ICAL grant with such a long timespan is heavy to calculate on the lock and might lead to unexpected results, like grant not being valid after i.e. 10 years.
The maximum timespan that can be specified via ICAL is 68 years with the current locks available on the market.
When not using a reccurence, but simple DTSTART/DTEND, it is recommended to use validFrom/validBefore combination instead of ICAL, that are simpler to calculate on the lock.
In your case validBefore would be null, meaning "unlimited".
We also recommmend you to update existing grants having 3000 year in ICAL to avoid any issues in the future.
To your question about the documentation of API changes, our current API version is always up to date and documented on developers.tapkey.io. We do not intentionally introduce breaking changes, but in this case it was a mistake. Again, we are very sorry for the inconvenience caused.
There is no specific endpoint to test the ICAL, what you can do is to try to create a test grant i.e. for yourself and remove it afterwards.
Thank you for your feedback, we will also try to improve the error message in this case.
I'll be straightforward:
What does it count as a "request" ? in some posts I've read a request is a "fetch", but on some others says 1 same operation of saving/updating might occur into several "requests".
What does it mean the system "throttles" your requests? I've heard if you reach the limit of 40 req / second, the system "throttles" your requests.... what does exactly mean this? and which criteria does it use? I'm guessing if you get a peak for whatever reason of lets say 80 req/second but after that you go back to your average 20/second the system won't charge you? if it's that, which criteria does it use?
If for any reason you need more requests per second... you simply have to pay the penalty? or is there any way around it?
Thanks a lot in advance.
Okay I think I found the key of the matter.
The scarce documentation says you have 40 requests/second per database. So if you are using private databases foreach user that means each user has 40 request/second .
This changes if you are using public database where all have access of course.
Someone please correct me if I'm wrong.
Thanks
I'm new to Facebook app development I hope I can get an answer here.
Is that possible to retrieve Facebook insight data for consecutive months?
I tried end_time=2010-01-01 to since=2010-01-31 and period=month but I got
The specified date range cannot exceed 3024000 seconds!!
How will I get like 2010-02-01 to 2010-02-28 and 2010-03-01 to 2010-03-31?
I have tried and used lots of examples but I couldn't succeed: How can I solve this problem?
The thing that has worked for me is very similar to what you are doing, with the difference being that I use the UNIX timestamp for SINCE and UNTIL.
Example:
https://graph.facebook.com/212686148747689/insights/
page_impressions_by_city_unique/week/?
access_token=QWERTYUI&since=1315699200&until=1320796800
(That's all supposed to be on one line, but it's easier to read it this way, at least for me.)
With this approach, you want to be careful and make sure that the difference between SINCE and UNTIL is not bigger that 90 days. Otherwise, you'll get an error, like so:
(#604) The specified date range cannot exceed 7776000 seconds
Finally, if you don't have a way of generating the UNIX timestamp automatically, go to a web site like:
http://www.epochconverter.com/
If anyone else has some better insights, please share. I hope this helps.
When doing Facebook graph search queries, you have the option of specifying the limit parameter. I am aware of the fact that the hard limit if 5000. However, when I do broad queries, I always retrieve about 500 results (between 480 and 540), even if the limit is well above that.
For example,
https://graph.facebook.com/search?q=doctor&locale=en_US&limit=1000&type=page&fields=id
Returned 527 results when I tried. Providing a valid access_token did not return more results.
Does anyone have any ideas as to why this is, and possibly how it can be overcome?
Facebook's API works on a "good enough" principle. It will keep fetching results until it considers that it's taking too long to respond and just reply with whatever it happens to have gotten. If you ask for limit=5000 you'll most likely always get less, but how much less depends on how complicated it is to retrieve those details.
The only way around it is using the 'paging' methods to the Graph API. However, I imagine each request will result in a new search and you may end up getting repetitive results.
We're getting a lot of "Application request limit reached" exception in our app. Looking at the insights page, it looks like "posts" from the graph API for "Calls access too much data" is the problem (108% right now). I would like to know what "Too much data" mean exactly ? Is it the number of bytes in a single call or the total number of bytes for a set of calls in a given period of time ? Or totally something else ?
Currently, I'm requesting posts one at a time so I can't see the first option being the problem. I don't understand why Facebook don't give any more info about this so if someone know the answer, I would really like to know.
Thank you!