we are using CSOM to communicate with SharePoint Online.
Since April 16th, 2021 we recognize http 400 responses from different parts of our code using CSOM calls from time to time. We added status 400 to our internal retry logic. Executing the same call a few seconds later succeeds. So pretty much a wrong status code.
It seems like SharePoint should generate a 429 throttling response at that time and somehow generates an incorrect 400.
Does anybody else experience the same?
Regards
Sven
Microsoft has fixed the issue on May 7th as reported here: https://github.com/SharePoint/sp-dev-docs/issues/6955
We could not find any http 400 failures in our logs after 5/7, so the fix seems to work in our case.
Related
Once in a while, my API calls to Acumatica will not return a response body, but still return a 200. The same call will be successful after a few minutes.
My guess is that I might be hitting limitations on the number of API requests per minute, or concurrent requests. It's hard to know when the requests are coming back as 200. There are no response headers that indicate an error.
Has anyone else experienced this?
I think you're on the right track regarding reaching a limit. I have experienced delayed requested but not declined requests from the API. There is definitely a limit based on the license on the Acumatica site. You should be able to take a look at the License Monitoring Console screen in Acumatica to see if there are any API violations -- Number of transactions per minute, delayed transactions and declined transactions are all logged and shown in the statistics on this page.
The image below shows an example of this page.
Does anyone know how to change an equity order utilizing the etrade API? I can do place order just fine but for some reason changing an equity order seems impossible! I have poured over the documentation and have failed at understanding how to do it.... I keep on getting a 9999 error
https://apisb.etrade.com/docs/api/order/api-order-v1.html#/definition/orderPreview
I couldn't get it to work either. I printed the errors and reason codes
https://api.etrade.com/v1/accounts/{myaccountkey}/orders/76/change/preview
<Response [405]>
Method Not Allowed
<Error>
<code>9999</code>
</Error>
405 isn't documented, and 9999 says The service you requested is not available at this time. Please try again.
Probably best to cancel and reenter the order, unfortunately.
I am currently trying to pull data from the Eventbrite API platform in Jupyter Labs. Sporadically, I am receiving a 406 Not Acceptable Error when I make the request. However, invariably, if I make the same request again a few minutes later the request pulls the data fine.
I've checked the usual things: ie that I have not gone over my request limits.
Here is the request I am currently making:
url = 'https://www.eventbriteapi.com/v3/events/search/?token=MY_TOKEN_HERE&location.latitude=42.34631505453378&location.longitude=-71.04174243961083&location.within=3km&start_date.range_start=2019-10-30T00:00:00Z&start_date.range_end=2019-11-30T00:00:00Z&expand=venue'
x = requests.get(url)
x
And the response:
<Response [406]>
Any thoughts on what the problem might be?
Yeah, I got an email from them a little over a week ago saying:
Hello,
We're reaching out today to follow up regarding the events/search/ endpoint. Thank you for your patience while we worked to reach a conclusion to the issue.
Access to the Eventbrite Event Search API (GET /v3/events/search/) will be shut down at 11:59 pm PT on Thursday, December 12, 2019.
We strongly encourage you to find and remove any code that makes requests to this Event Search API from your applications in advance.
Why is this happening?
We’re removing the Event Search API to further improve the Eventbrite platform and allow us to support more Creators and their events. Allowing public access to this particular API was impacting our platform and the high level of service we strive to provide to our creators and their attendees. We are able to provide alternative access to retrieve your event data through our Event APIs (see below).
What is the replacement API?
To get Events via our API, please see:
• Retrieve an Event by ID — GET /v3/events/:event_id/
• List Events by Venue — GET /v3/venues/:venue_id/events/
• List Events by Organization — GET /v3/organizations/:organization_id/events/
If you’re retrieving private events on behalf of another user, you can complete the app authorization flow. If you’re interested in retrieving public events on behalf of many Eventbrite creators, you can apply to our distribution partner program.
We apologize for the delay in communication regarding this decision, as well as for the inconvenience and frustration this change has caused
Regards,
Eventbrite Developer Support
So it looks like that's finally confirmed as dead at least.
FYI... this is an an ongoing Eventbrite API issue that is causing problems for many. See: https://groups.google.com/forum/#!topic/eventbrite-api/-E0MG7THMsc
As the subject line states, all API calls for the past 6 days have resulted in Error 400 ThrottleUser responses. Tried a new api key; pox, json and service connections.
Is this happening to everyone? Does anyone know how to tell them it is not working?
Support can be requested here: https://www.bing.com/webmaster/support
as suggested here: https://social.msdn.microsoft.com/Forums/en-US/f24edc35-5aab-445a-91b8-73a1982019d7/webmaster-api?forum=whatforum
I consistently get this response
{ error: { status: 500, message: 'Server error.' } }
when I try to retrieve all playlists for my user using this endpoint
GET https://api.spotify.com/v1/users/{user_id}/playlist
I am doing this repeatedly as a test case while I develop the plumbing for my Spotify web api application.
Sometimes it fails when I start at offset 0. Sometimes it succeeds at offset 0 (and offset 50, 100, 150, etc.) and fails later. I have about 900 playlists.
It fails whether I get 20 playlists at a time or the maximum of 50.
I see nothing unusual in the response headers.
Is this a bug on the Spotify's end? I assume since I'm getting status 500 that this is not related to hitting a request rate limit of some kind, or some error in my request.
I would appreciate any insight anyone has to offer.
Responses with status code 500 from the /v1/users/{user_id}/playlists/ endpoint can be caused by a number of reasons, none of which is your application's fault. There are cases where a user's list of playlists (or an individual playlist) cause temporary issues in Spotify's backend. This occurs more often if the list of playlists have a lot of revisions, e.g. the user has an unusually large amount of playlists and have removed, added and moved them around a lot. We're working on resolving this but meanwhile we ask you to try again.
This isn't related to any of the query parameters sent in the request, it's simply an intermittent error.
Is this a bug on the Spotify's end? I assume since I'm getting status 500 that this is not related to hitting a request rate limit of some kind, or some error in my request.
Spotify's Web API return a response with status code 429 if the request has been rate limited. A list of which status codes are returned from the Web API can be found in the User Guide.