This is the documentation of the API I'm trying to make a request to.
Relevant section:
Public Data Functions
Ticker
GET https://kiwi-coin.com/api/ticker/
Returns JSON object:
last - last BTC price
date - price date
high - last 24 hours till date price high
low - last 24 hours till date price low
vwap - last 24 hours till date volume weighted average price: vwap
volume - last 24 hours till date volume
bid - highest buy order
ask - lowest sell order
Here's my code:
$.ajax({
type: "GET",
url: "https://kiwi-coin.com/api/ticker/",
});
Yep, there's no way of handling the response. Ignore this for now,
I'm just focusing on getting the request to work.
Here's the error I get in the console:
Failed to load https://kiwi-coin.com/api/ticker/: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://cloud-rooster.glitch.me' is therefore not allowed access.
What am I doing wrong? This API works for other users (e.g. bots).
I checked out the other questions with a similar title, but from what I could make out the answers all involved making changes to the server, which isn't an option in this case.
If the API server doesn't support CORS, there are two options:
JSONP. Though you can't make cross-origin XHRs without adequate permission, you CAN include a JavaScript file from anywhere. If the API server returns something like callback({ json data ...}), then you can use the data without having to jump through hoops. However, it doesn't seem like KiwiCoin supports that.
Run your own server from the same origin as your client application (probably the same server that hosts your HTML/JS files), and have endpoints on your server that forward to the API server. This is foolproof.
One thing I noticed from looking at your code is that you have calls to process.env, which doesn't exist in the browser. That might be the sign you need to try option #2!
It turns out I was running the function from the client-side (in the browser), rather than server-side (in a Node.js environment).
Duh!
Problem solved.
Related
Having a weird problem with Paypal API. I'm using the Subscriptions API an before creating a subscription, I need to create a plan. In the Sandbox enviroment, the resource /billing/plans (https://api.sandbox.paypal.com/v1/billing/plans) works fine, but in Live mode (https://api.paypal.com/v1/billing/plans) I get ´404 Not Found´ with an empty body. Didn't found any hint at the docs. Any ideas?
https://developer.paypal.com/docs/api/subscriptions/v1/
Paypal's customer service is very poor. We will not get any answer from them.
Temporary, we can use backend to create via https://www.paypal.com/billing/plans/plan/create
I contacted the Merchant Technical Support (https://www.paypal-support.com/s/?language=en_US), they made a correction and now it's working again.
A couple of easy mistakes you could have made which I made which give rise to 'the blank screen'. A very easy one: Check that your country codes comply with the iso standards. I was using UK instead of GB. Particularly your shipping address. You can replicate this error by putting in the wrong country code.
Also ensure that your start_date is greater than the current date. The test samples contain old start dates which are behind current dates. Increment the date function with 36000 instead of 3600 to ensure that your start date is greater than an extra hour from your current date or just hardcode a very late date. Your server might be operating at a different timezone.
The token passed was not found in the system....If you have a blank screen it is likely that the access token is not being passed after the 'first run' because you do not have an approval link as a result of the pre-passing error. It sounds like it could be a basic content error but you have likely checked for this.
Check the runtime log file and look out for the approval link. A successful 201 pass will give you something like the following.
"links":
[
{
"href":"https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-22608875RF361971P",
"rel":"approval_url",
"method":"REDIRECT"
},{
"href":"https://api.sandbox.paypal.com/v1/payments/billing-agreements/EC-22608875RF361971P/agreement-execute",
"rel":"execute",
"method":"POST"
}
]
These are some of the errors that I have encountered which might be of use to you perhaps.
I would like to do the following using OKTA api:
One time, I would like to pull the entire system log.
Going forward I would like to pull only the days log information.
The challenge that I am facing is whenever I get the logs, I only get 1000 records. How do I get the whole days log, it maybe more that 1000 records. Is there some body who can help me with a piece of code which shows how to do this.
Thanks
You can use the Events API to retrieve this information. This API supports Pagination so you can retrieve all the events for a particular filter (like all events after a certain point in time).
1000 is the default limit for the Events API because this object can potentially contain a lot of data.
However, you can specify how many records for a specific time range are returned via the Events API using filters. For example, the following GET statement would retrieve the first 100 successful login requests since 1-Mar.
https://{{YOUR_COMPANY}}.okta.com/api/v1/events?limit=100&filter=published gt "2015-01-01T00:00:00.000Z" and action.objectType eq “core.user_auth.login_success"
If there are more than 100 records, you can get the next set by passing rel=“next” in the next request header. If you wanted to get only messages for today, you could change the date.
I've noticed when retrieving a story/defect after first updating it, sometimes the retrieve response returns the field values as if the update never happened. Retrying the retrieve after a short delay (~500ms) returns the updated field values as expected. Is this a known behaviour? Is there any way of avoiding this?
I'm using the Rally API 2.0 - https://rally1.rallydev.com/slm/webservice/v2.0/
The update is being performed using this URI:
POST /slm/webservice/v2.0/Defect/14173461229?key=<key> HTTP/1.1
I'm retrieving the story after update as follows:
GET /slm/webservice/v2.0/artifact?query=(ObjectId%20=%2014173461229)&start=1&pagesize=20&fetch=true HTTP/1.1
What is your integration doing that it needs to re-poll the artifact within < 1 second of POST'ing an update? Is there a second process that does polling that is revealing the latency for the updates? Does your integration run multiple threads? Does the response time vary at all depending on time of day, etc.? There are any number of factors that could be at play here, but 500 ms doesn't seem like an un-reasonable refresh rate given factors such as latency over HTTP/S as well as server-side database and cache updates. That said, for an in-depth look you may wish to inquire with Rally Support (rallysupport#rallydev.com) as they have tools that can help evaluate server-side response time corresponding to requests by specific UserID.
Context: let's say we want to retrieve whole list of Starred repositories by given User periodically (ones per day, hour or few minutes).
There are at least 2 approaches to do that:
execute GET to https://api.github.com/users/evereq/starred and use Url with rel='next' in 'Link' Response Headers to get next page Url (we should do that till we get no "next" page in response, mean that we reach the end). Seems that is recommended approach (by Github).
iterating 'page' parameter (from 1 to infinite) using GET to https://api.github.com/users/evereq/starred?page=XXX till you get 0 results in response. Ones you get 0 results, you finish (not recommended because for example instead of page numbers Github can move to "hash" values. Github already did it for some API operations.).
Now, let's say we want to make sure we use Conditional Requests (see https://docs.github.com/en/rest/overview/resources-in-the-rest-api#conditional-requests) to save our API usage limits (and traffic, trees in the world, etc.).
So we add for example 'If-None-Match' to our Requests Headers and check if response Status is 304 (Not Modified). If so, it means that nothing was changed from our last request. That works OK.
The issue however that what we have in 1) and 2) above, related to the way how we detect when to stop is NOT working anymore when you use Conditional Requests!
I.e. with approach 1), you don't get Link Response Headers at all when you use Conditional Requests.
So you will need to execute one more request with page bigger than page for which you already have ETag and see that it return 0 results and than you know you are done. That way you basically "waste" one request to Github API (because it miss Conditional Requests Headers).
Same with approach 2), you basically have 0 responses in every request with status 304... So again, to know you are done, you need to make at least one additional request which do return 0 results.
So the question is: when we do conditional requests with the fact that Github API does not send back Link Response Header (at least with queries using ETag which result Status 304) how could we know when to stop paging? Is it a bug in Github API implementation OR I miss something?
We don't know maximum page number, so to get when to stop we should execute one more "waste" request and check if we get 0 results back!
I also can't found how to query Github for total count of starred repositories (so I can calculate how many pages I should iterate in advice), same as responses does not include something like "X-Total-Count" so I know when to stop using simple math for pages count.
Any ideas how to save that one ('end') request and still use Conditional Requests?
If you do one request per day, it's OK to accept such waste, but what if you do such request ones per minute? You will quickly use all your API usage Limits!
UPDATE
Well, after a few more tests, I see now following "rule" (can't however found it anywhere in the docs, so note sure if its rule or just assumption): if user star something new, result for EVERY requested page contains different ETag value compared to previous and does not have status 304 anymore! That means that it's enough to just request first page and check for status. if its 304 (not modified), we do NOT need to check next pages, ie we are DONE as nothing was changed in any page. Is it correct approach or just coincidence?
We indeed return pagination relations in the Link response header when the content has changed 1. Since we don't support a since parameter for that call, you'll need to sort by most recent results and maintain a client-side cursor for the last known ID or timestamp (based on your sort criteria) and stop paging when it shows up in your paginated results. Conditional requests will just let you know if Page 1 has changed.
We haven't settled on a way to return counts on our listing methods, but a really low-tech solution is to set the page size to 1, grab the rel=last Link relation and check its page parameter value.
Hope that helps.
I'm tring to search locations with the Instagram API in my application but also when testing with Apigee, I get 500 Internal server error, and Oops, an error occurred.
Apigee: https://apigee.com/console/instagram
Authenticate yourself and add this URL: https://api.instagram.com/v1/locations/search?lat=40.758896&lng=-73.985131
It should return Time Square locations. It worked a few times in the past, but currently it doesn't.
It would be an overkill to use the Foursquare api to search for locations, then pass the location id to Instagram. Is that the only way to get around this? Because once you know the location's ID it works ok.
My possible solution would be to let the user find the desired location here: http://worldc.am/id/47383924f964a520444c1fe3
And use the v2 foursquare API location ID for Instagram.
The Instagram API is pretty bad in that regards - it often just says "Oops an error occured!", without giving you any more info.
I believe their servers have a really low time out limit. Add the parameter distance=500, or even less, and you won't get this error any more. Basically, in a high density area (like a big city), you need to specify a small distance number, otherwise Instagram's server just times out while serving your request.