We Keep Coding

Why is my google API key breaking after 100 requests

I'm validating addresses to make sure they exist. I'm using the google API to do this. I have a google API key and it works great.... until I go over 100. At request 110 I get this
{
candidates: [],
error_message: 'You must use an API key to authenticate each request to Google Maps Platform APIs. For additional information, please refer to http://g.co/dev/maps-no-account',
status: 'REQUEST_DENIED'
}
All I'm doing is looping through a list of addresses. It works perfectly up until then. And it's always at the exact same point.
I've tried slowing it down (thinking i'm making too many requests too quickly) by wrapping it in a while loop and only doing 50 at a time, but all that does it slow it down but still crashes at exactly 110.
Any ideas why or how or how to fix it? It is an unpaid API key if that helps (wondering if they have a request limit, I can't find anything saying they do)

While it seems most likely that you have reached the quota allowed on an non-billing account, the status code should read "OVER_QUERY_LIMIT" which indicates that you are over your quota, rather than "REQUEST_DENIED", which you are getting.
https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes
Further down, on the same page you have a suggestion as to the likely cause:
"REQUEST_DENIED" indicates that the request was denied. Possibly because the >request includes a result_type or location_type parameter but does not include an >API key or client ID.

You have to set up a billing account.

Turned out to be one of the parameters I was sending to it had a special character that was breaking it. I printed out the URL before sending it to see what was going on.
TLDR had to use encodeURIComponent on the addresses I was sending, before sending them

Unsplash API: How to retrieve Access_Token for authenticated access-login by browser?

I needed to submit an approved-account access to Unsplash API, so as to access certain links for access approval. Given that the replies from the support team has taken more than a few days, I would just like to seek out additional help to resolve in retrieving the access_token for new requests-submissions via GET / POST methods.
The original website was working perfectly, till when I had wanted to get ready for submission for production stage and had wanted to prepare potential increases in requests to the Unsplash API.
However, the approval process entailed certain setup criterial, which I totally missed during my development phase and sought to iron out as soon as possible. One of the key component is to resolve your UTM links, which you may find here as the ideal reference: https://help.unsplash.com/en/articles/2511315-guideline-attribution.
My challenge then was that I had attempted to use the official javascript API, Unsplash-Javascript-API (https://github.com/unsplash/unsplash-js#authorization), in an effort to make the authentication / request processes simpler for my webapp to call.
Though most GET requests do work, given that a specific URL of links via "download_location" (https://help.unsplash.com/en/articles/2511258-guideline-triggering-a-download), has to be used instead, it will then require an authenticated request per new submission request by the webapp.
The final challenge then is that apparently it is not clear how the official Unsplash-Javascript-API actually pulls the "authenticated" request, as I was unable to find it on the website, so that I may retrieve the current-access_token for requests' usage.
The basic codes I am using via the API is the following, however I am confused what is the actual maximum request I may pull per page, I am hoping to get 100 returned images' details, but only gotten a maximum of 30 per time. Anyone can also help to confirm is there a workaround to increase this 30 to 100?
Retrieving a Collection of Photos
unsplash.collections.getCollectionPhotos(urlAPI, 1, 100, "Popular")
.then(toJson)
.then(jsonData => {
console.log("jsonData", jsonData);
});
So, currently my website is unable to launch for nearly 1 week plus, as I am just awaiting the final confirmation or additional help from the customer support end of the official Unsplash Team.
Hopeful that someone may help to assist me in clarifying the codes so that at least I can get one step closer to sorting this "official authenticated" process out, and take away one lesser step to getting my approval access for production ready.
Thank you in advance!

Given multiple tries. I wasn't able to retrieve the Access_Token reply, given that there is a pre-authorization step that I wasn't able to find any working solution to.
The current and clear limitations to the API are:
Maximum of 30 images request per GET request.
The official javascript API, Unsplash-Javascript-API (https://github.com/unsplash/unsplash-js#authorization) works but there is not clear or easy way to retrieve the "Access_Token" for a session usage.
Multiple async AXIOS / FETCH requests may not be "compiled successfully" when using ReactJS ContextProvider function prior to the first render. Therefore, an empty array will be shown instead on the final initial render.
Ultimately, my chosen solution is current to break down the images list to the most priority, with the limitation of only 30 images on retrieval, and still store into the original collection and retrieve it.
The other alternative is to actually download and load the images to your own server to load it, which may also be a faster route.
Sadly enough, the Unsplash API team doesn't response as frequently to assistance and my last contact was roughly 1 month ago, though I have attempted to update to their requirements but there were no feedback thereafter.
Thus, it will tentatively be better for you to just build an alternative solution than to rely on the team for a feedback, unless you are a paying client.
Good luck to the others on this! Cheers!

payone integration with creditcardcheck

I have read almost everything there is on the Internet (almost no examples) and studied the (very limited and confusing) documentation.
I have a client were I am integrating payone, and I am not getting any further.
So I used the API client documentation and integrated the iframe client api example with creditcardcheck on page 35 (chapter 3.1.5.5). This works fine I receive the answer and a pseudocardpan.
As explained in the quick start guide, I then start the "preauthorization", using the server api with the pseudocardpan. I send all the necessary parameters again, and I end up on the server payone with status = approved .
I assume this is then successfull. However, what or how should I proceed? What is the transactionUrl for? Maybe someone has experience with payone.

sorry to hear you're having a tough time implementing a Payone interface. We are currently working on providing more insightful examples. Please bear with us for a little longer.
Meanwhile, I'll gladly help you with continuing your integration. After the successful preauthorization, you'll need to store the txid for further reference to this transaction. To collect the money from the creditcard, you'll need to send a capture request with the amount you wish to collect and the txid as a reference (see the docs for a full list of required parameters).
If you don't want to send a capture request afterwards (for instance if you want to collect the entire amount immediately after the customer completed their order) you can send an authorization request instead of the preauthorization and leave out the capture part.
The transaction status URL is used to asynchronously inform your application about status changes in Payone transactions. For instance in a prepayment setting we'll send a PAID notification as soon as the customer paid the amount to your bank account.
Best,
Florian (Technical Partner Manager # Payone)

I understand that once the response comes back that it has been approved, then it is approved - all the details were correct and authorisation was successful.
If you are doing a preauthorization then you will need to follow that with a capture to actually take the payment. In some legislative environments, for example many US states, you cannot capture the payment until you finally ship the goods from an online shop.
If that is not a problem (e.g. paying invoices, running an online shop in the UK), then use authorization, which does a preauthorization and capture all in one step. Apart from the name of the request, the details of the message you send is identical.

Getting Instagram's Current Like and Follow Limit Via API

I own a website that automates Instagram actions, currently I'm getting 100 likes/hour and 100 relationship posts/hour (I know it says 60 for relationships but I've been getting 100). I enforce signed headers, and since I've added my email address I've noticed no 400 errors, just some advice.
So my question is, how can I find my current request limit regarding likes and following/unfollowing? I know in the header they provide how many requests you've made compared to the 5,000 in one hour, but I want to know specifically when I'm going to get the 429 "OAuthRateLimitException" error, so I don't have to hit this limit every hour, I've noticed after getting this error every hour for hundreds of users, it does not look good for my app.
If anyone could tell me how to get how many like requests I've made in the hour, so I can stop before receiving the 429 error, that would be great. I'm using JavaScript, ajax and PHP to make my calls.
Thanks.

You are likely not using Oauth tokens for each user. By doing so, the rate limit will scale by the number of people using your app.
As for telling how many you have left, it should be in the HTML header response. From their documentation:
HTTP Header
Information regarding the global rate limits is included in the HTTP
header on the response to each of your calls, which enables your app
to determine its current status with respect to these rate limits. The
following fields are provided in the header of each response and their
values are related to the type of call that was made (authenticated or
unauthenticated):
X-Ratelimit-Remaining: the remaining number of calls available to your
app within the 1-hour window
X-Ratelimit-Limit: the total number of calls allowed within the 1-hour
window

from the manual:
HTTP Header
Information regarding the global rate limits is included in the HTTP
header on the response to each of your calls, which enables your app
to determine its current status with respect to these rate limits. The
following fields are provided in the header of each response and their
values are related to the type of call that was made (authenticated or
unauthenticated):
X-Ratelimit-Remaining: the remaining number of calls available to your
app within the 1-hour window
X-Ratelimit-Limit: the total number of calls allowed within the 1-hour
window
https://instagram.com/developer/limits/

Global rate limits are applied inclusive of all API calls made by an app over the 1-hour sliding window, regardless of the particular endpoint. The limits are applied independently from each other; authenticated calls are not counted against the rate limit for unauthenticated calls and vice-versa.
HTTP Header
Information regarding the global rate limits is included in the HTTP header on the response to each of your calls, which enables your app to determine its current status with respect to these rate limits. The following fields are provided in the header of each response and their values are related to the type of call that was made (authenticated or unauthenticated):
As you can see it's not specific to an endpoint it's based on the overall requests made per access token(if authenticated).
So I'm just wondering if it is even possible to check an access tokens current amount of requests specific to a particular endpoint.

Is there a maximum HTTP status code message length?

I'm working on a project where I'm building the frontend and someone else is building an API. I was proposing the following structure for all requests, sent as JSON:
{
"success": true, // true/false
"message": null, // a string if success==false indicating the error
"data": {} // The actual data in the response
}
They are more interested in making the API more RESTful, and instead of a "message" field they are proposing sending a message back in the status code message, in the HTTP headers, such as:
HTTP/1.1 401 Authentication Failed for john.smith#example.com. Please log in again.
and the frontend would display "Authentication Failed for john.smith#example.com. Please log in again." in a popup or something.
I'm worried about length restrictions, but I couldn't find anything indicating no maximum length. Should we ensure we keep those messages to a minimum length? Is there a good reason to not do this, and instead send it back as content (JSON or plain text)?

A little testing will go a long way, but you should be okay to do this and in fact the RFC says specifically:
The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol.
The only possible concern you may have is header size (some servers may have limitations, but I think they are all relatively large) and how some older browsers may react to this. Frankly I think it makes more sense to use the response body since it's easier to interpret and clear, but there shouldn't be anything wrong with your approach.

I want to add, although there might be no limit in the specification, there is a real chance of implementations to truncate the status message, as I discovered, when I was trying something similar as the OP with Jetty 9.4.14 .
It took me some time to find the reason for the truncated message - there is a hard coded, not configurable limit of 1024 characters [see method getReasonBytes(String)].
(could not post this as comment due to lack of reputation)