Linkedin Creative API endpoint request limit per day seems to be dropped from 1 million requests to 5000 requests.
The API returns the response after the 5000 request limit is raised - HTTP-error-code: 429, Error: Resource level throttle APPLICATION DAY limit for calls to this resource is reached.
Earlier Base URL API endpoint with 1 million requests - https://api.linkedin.com/v2/adCreativesV2. Reference
Latest Base URL API endpoint with 5000 requests - https://api.linkedin.com/rest/creatives. Reference
Related
We published an API through the WSO2 API Manager (currently v2.1 but will soon switch to v2.6) Publisher and throttled it to 100 req/s max (advanced throttling rule).
What will be the HTTP return code in case of too many requests reaching the maximum allowed per second?
This WSO2 documentation page:
https://docs.wso2.com/display/AM260/Error+Handling
gives many APIM error codes (including those for throttling limits) but the binding with HTTP code is incomplete and we need to give it to our client.
Is the 900802 APIM error code bound to the HTTP 429 error code as is the 900801?
What about codes between 900803 and 900807?
Thank you for your help.
The following are the HTTP status codes.
900801 - 503
900802 - 429
900803 - 429
900804 - 429
900805 - 429
900806 - 429
900807 - 429
You can identify those codes using [1], [2] and [3].
[1] - https://github.com/wso2/carbon-apimgt/blob/53123b847047564cc342cbbed76c9ccf8a097516/components/apimgt/org.wso2.carbon.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/gateway/handlers/throttling/APIThrottleConstants.java#L23
[2] - https://github.com/wso2/carbon-apimgt/blob/c95361146f7ee15f80f61611a97066545c35664d/components/apimgt/org.wso2.carbon.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/gateway/handlers/throttling/ThrottleHandler.java#L620
[3] - https://github.com/wso2/carbon-apimgt/blob/53123b847047564cc342cbbed76c9ccf8a097516/components/apimgt/org.wso2.carbon.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/gateway/handlers/throttling/APIThrottleHandler.java#L267
I am using the Google geo-coding API with its API Key; I am using code as below:
string url = "https://maps.googleapis.com/maps/api/geocode/xml?address=" + area + "," + City + "&Key=ABZIXXXXXXXXXXXXXXXXXXXXXXXXXXX"
After handling some requests I am getting the status code "OVER_QUERY_LIMIT";
does any one have any idea about this problem?
Either you are sending too many requests or you are sending the requests too fast: https://developers.google.com/maps/faq?csw=1#usage_exceed
The standard version is limited to 2 500 daily requests and 10 requests per second:
https://developers.google.com/maps/documentation/geocoding/usage-limits
You should throttle requests to stay within allowed per second limit. If you need more than 2 500 daily requests you can enable Billing and get 100 000 daily requests.
The Xively API is rate-limited but I'm trying to understand what the limits are so that I can adjust my client accordingly. In fact there seems to be more than one limit: in some cases I see a 406 (Not acceptable) HTTP response, and other times I see a 403 (Rate too fast) HTTP response.
I think the 406 occurs when the number of API calls exceeds a certain rate - in my test the limit seems to be around 25 API calls per minute. The HTTP response includes a "Retry-After: 5" header.
If my test queries more than one device the limit still seems to be 25 API calls per minute - I don't think this limit is per device. The 406 error code is not mentioned in the Xively API documentation.
The 403 error code is described in the Xively documentation: https://xively.com/dev/docs/api/communicating/usage_limits/
The page talks about per-device limits and suggests the limit is different for reading and writing but doesn't really give any more detail than that.
Can anyone shed any more light on what the limits actually are? I am currently using a development-mode account - it's possible the 406 error only occurs in development mode. However the link mentioned above suggests you can get the 403 error in production mode too.
The Google translate API FAQ at https://developers.google.com/translate/v2/faq#technical states that the maximum number of characters per request is 5000. However, I am unable to send more than 2000 characters without getting HTTP error 414: The requested URL /translate... is too large to process.
I am getting this from my .NET app but have also reproduced the same error from Fiddler.
Below is the URL I am sending (just over 2000 characters). Am I misunderstanding the 5000 character limit?
https://www.googleapis.com/language/translate/v2?key=MYKEY-MYKEY-MYKEY-MYKEY-MYKEY-MYKEY-KEY&source=en&target=es&q=From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0A
You'll need to POST the data if you wish to process more than 2000 characters:
All other query parameters are optional. The URL for the GET,
including parameters, must be less than 2K characters.
Note: You can also use POST to invoke the API if you want to send more
data in a single request
https://developers.google.com/translate/v2/using_rest
Some hours my web site's server has too much load.
Which HTTP status code should I send to the Googlebot that visits my website?
Is "269 Call Back Later" this suitable for this case, or 503 Service Unavailable or do you have any more suggestions?
503 means the service is temporarily unavailable so it is appropriate to use while the server is overloaded. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
The Wikipedia article defines 269 as the initial response for a request that must be processed asynchronously. 269 means the request added something to the server's "queue" of things to do and the server will have a response available as soon as possible, whereas 503 means the server will not "remember" the request.
I've never heard of 269, though, and the first Google result for it is this question, followed by the Wikipedia article.
Another option is a 429 - Too Many Requests response.
Defined in RFC6585 - https://www.rfc-editor.org/rfc/rfc6585#section-4
The spec does not define how the origin server identifies the user, nor how it counts requests.
For example, an origin server that is limiting request rates can do so based upon counts of requests on a per-resource basis, across the entire server, or even among a set of servers.
Likewise, it might identify the user by its authentication credentials, or a stateful cookie.
Also see the Retry-After header in the response.