We occasionally get this error back when trying to POST to the /events endpoint.
"error": {
"errors": [{
"domain": "usageLimits",
"reason": "quotaExceeded",
"message": "Calendar usage limits exceeded."
}],
"code": 403,
"message": "Calendar usage limits exceeded."
}
}
However, we seem to be well below our quota. Our quota is 20,000 requests per minute, and our seven-day peak is under 12,000. Yet these errors persist. (Our quota for requests per user per minute is 60,000,000 which doesn't make any sense.)
We have one user who is creating a large number of events (26,000 over the last 30 days) and that user gets the bulk of these messages, but other users get them, too...users that we've confirmed are well below these kinds of limits.
We found this workspace administrator help document that indicates some types of Workspace accounts (new, cheap, etc.) might have tighter restrictions. Do those restrictions apply if somebody is Oauthing in to our project to use the Google Calendar API?
Related
Running into an issue when trying to call the Posts API.
I'm getting a list of the authenticated user's posts through https://api.linkedin.com/rest/posts?q=author&author=AUTHOR_URN (https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/shares/posts-api?view=li-lms-2022-07&tabs=http#find-posts-by-authors) which worked yesterday but not anymore today.
I am convinced I changed something between then and now, but whatever I do I cannot seem to get the request to work anymore.
The error returned does not give me a lot of information either:
{
"message": "Internal Server Error",
"status": 500,
"code": "INTERNAL_SERVER_ERROR"
}
I also created a request to fetch images yesterday, which does still work:
https://api.linkedin.com/rest/images/ids=List(IMAGE_URN) (https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/shares/images-api?view=li-lms-2022-07&tabs=http#batch-get-images)
URN I'm using for the /posts request is formatted as follows: urn%3Ali%3Aorganization%3A<REDACTED> (where <REDACTED> is the numeric author identifier).
Confirmed the headers are the same between the /posts request and /images request.
Headers for reference:
Authorization: Bearer ACCESS_TOKEN_REDACTED
X-Restli-Protocol-version: 2.0.0
LinkedIn-Version: 202207
Is there anything I'm missing here that I need to get my /posts request working?
Thanks in advance!
Talked to someone from LinkedIn support since the issue occurred for me. Their response:
It's possible that you were getting that error due to a small hiccup on our side at that time - This can happen when we deploy updates or fixes.
Since then I've not seen this happen anymore, so expecting this is the case. Closing as answered.
I'm having a hard time understanding how SNS handles response messages. My SNS subscriber is a page that might go down or simply return a 4xx error.
For some reason though, it seems that SNS is treating requests that return 4xx error codes as successful.
How can I make it fail when the response code is 4xx and not only 5xx?
From the logs we can see that the subscriber is returning a status code 404 Not found, but despite that, the status of the request is still SUCCESS.
{
"notification": {
"messageMD5Sum": "fd746e97153916fd99bba*********",
"messageId": "be666c50-8de5-594b-9e77-*********",
"topicArn": "arn:aws:sns:us-east-1:060758096283:*********,
"timestamp": "2021-11-23 14:21:23.778"
},
"delivery": {
"deliveryId": "ef278086-2a70-5512-a191-da90d1534d24",
"redrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:*********:*********-DLQ\"}",
"destination": "*********/subscriber.php",
"providerResponse": "Not Found",
"dwellTimeMs": 80,
"attempts": 1,
"statusCode": 404
},
"status": "SUCCESS"
}
This is causing me issues with monitoring, as It's very hard to know if my requests are actually successful or not without manually looking them up.
SNS's job is to deliver a message to the endpoint. If the endpoint responds with a valid status code (not a 5XX failure), it considers the delivery of the message successful. How that message is responded to is up to the receiving API.
To be precise, only status codes outside of the range 200 - 499 will be considered as a failures and retried according to your retry policy as per https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html. Once the max number of retries has been exhausted, the message will be delivered to a DLQ if one is configured.
I make a post request with a different json file every hour and I wondered if I can make this automated? I searched online and it looks like it can be done with collection runner or monitors?
URL: https://api.keepa.com/tracking?key=MY_API_KEY&type=add
Headers: Content-Type application/json
Body:
{"asin":"value",
"ttl": value,
"expireNotify": value,
"desiredPricesInMainCurrency": value,
"mainDomainId": value,
"updateInterval": value,
"metaData": value,
"thresholdValues":{"thresholdValue": value,"domain": value,"csvType": value,"isDrop": value},
"notifyIf": value,
"notificationType": value,
"individualNotificationInterval": value},
One json file has 1000 of these object. I have 100 json files.
Can someone give me some information about this please? Can I automate it with collection runner?
There are too many ways to schedule your Postman requests and one is creating a Postman monitor. Check this article to learn how to start. If you want to specialize your request you can use the Pre-request Script and Tests section.
Sample Pre-request:
Sample Test:
Monitor Console Log:
PS: There is a quota for free Postman accounts. Total 1000 requests per month for Postman Monitoring. Buy a premium account or learn how to use Newman (Postman CLI) and how cron jobs work for making the same thing for free.
We're using LinkedIn API for a very simple case:
authenticate (either through SDK or web view)
use token to fetch profile
Today we have noticed a huge degradation of service. Simple profile calls response time is in the range of 500ms - 12000ms and sometimes it returns 500.
Slow response can be easily reproduced by using the REST console from developers guide:
https://apigee.com/console/linkedin
with more than half of the requests taking more than 10sec to respond.
We also noticed tha sometimes requests return 500 from LinkedIn:
<-- 500 https://api.linkedin.com/v1/people/~:(id,first-name,last-name,email-address,formatted-name,headline,location,industry,num-connections,num-connections-capped,summary,specialties,positions,phone-numbers,public-profile-url,picture-url,picture-urls::(original))?format=json (17808ms)
{
"errorCode": 0,
"message": "Internal API server error",
"requestId": "3FXP4W2HD2",
"status": 500,
"timestamp": 1519643223202
}
<-- END HTTP (138-byte body)
This looks like a timeout on server side maybe at some point, hence failure.
Given that sometimes the API responds quickly, it does feel like one of the servers outage maybe? (I might be wrong).
Would be great to know if:
there is a status page for the LinkedIn API that can tell us about the problems and how / when they are getting addressed.
can we treat V1 API as reliable at all? There was a similar (but easier to workaround) problem with fetching profile just couple of weeks ago.
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.