I am using ExactOnline API to fetch the transactions, my API is working fine, but suddenly the Error 403: Forbidden - The division is blocked error occurs and API return the empty result.
Please help.
Thanks.
An HTTP 403 with reason "The division is blocked" typically means the administration is temporarily blocked by a process that needs exclusive access to the administration. Examples are:
One of the company's users is creating or restoring a backup of the administration.
Exact is moving the administration to a different database. (After office hours; users are notified in advance through Exact Online's workflow system.)
API clients should be able to handle this situation. The typical solution is to try again at a later time.
You can find a full list of response codes here:
https://support.exactonline.com/community/s/knowledge-base#All-All-DNO-Content-respcodeserrorhandling
Related
We recently signed up for the tool Oribi. For some reason the Oribi platform is returning the following error and can't connect to our Analytics accounts via the API.
Forbidden: status 403 reading GoogleClient#getWebPropertyProfiles
We've been trying to solve this for weeks now and got the following message from them today - any advice or possible solutions to explore?
While the error we receive from Google indicates that there are insufficient permissions to access the Properties, when looking at your account, everything seems to be properly set.
The next step would be reaching out to Google to inquire about this.
While we won't be able to do this on your behalf, I'll be happy to assist with providing all the relevant information to make sure everything is clear so they can take a look into it.
The situation is as follows: When sending Google the API request to connect the Web Property, the following error is thrown back: Forbidden: status 403 reading GoogleClient#getWebPropertyProfiles.
The user connected to Google has Admin permissions on the account.
When trying to getting response from https://developer.api.autodesk.com/bim360/admin/v1/projects/:projectId/activities it rises 403 error with details - Route not enabled for account. But, for example, request https://developer.api.autodesk.com/bim360/admin/v1/projects/:projectId/users has successfully responsed. User has all admin permissions.
Can every one help with that? :) Are there another ways to get project activities?
Unfortunately, activity API is not released yet, so you cannot use it currently. Please stay tuned with our official announcement in the further. Apologies for the inconvenience!
I recently got access to the Amazon Product API, and I was trying to experiment with some requests both on my Node.JS environment and on ScratchPad.
But all my requests come back as Error 429 - Too many requests. So far, I haven't been able to make any successful requests using the API.
Has anyone had this issue before? How can I solve this?
I had this error message when trying to access the API via the python SDK. I figured out that besides acces_key, secret_key, and partner_tag I needed to set host, region, and marketplace to the country-specific values according to https://webservices.amazon.com/paapi5/documentation/common-request-parameters.html#host-and-region.
While this seems obvious in retrospective, the error message 429 "too many requests" does not really hint to fix that.
I'm synchronizing Office 365 mail folders via the Office 365 REST API by doing a GET on me/MailFolders/{folder_id}/messages. For two different accounts, I've recently been getting 500 responses to these GETs with the error code ErrorMessagePerFolderCountReceiveQuotaExceeded and error message "The number of received messages has exeeded the quota for the folder." (Typo theirs, not mine.)
I can't find any documentation on this error. What does it mean? What should I do to fix this situation?
I couldn't seem to find any documentation for it either.
From the error message, it seems it might be related to the "Maximum number of messages per mailbox folder" limit on Exchange Online. Do you know if the folder contains 1M+ messages?
https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx#MailboxFolderLimits
I guess my other idea would be that you're getting too many messages in too short of a time period. Suggestion would be to use the endpoint GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages with $deltaToken and $skipToken to skip previously synced messages.
https://msdn.microsoft.com/en-us/office/office365/api/mail-rest-operations#synchronize-messages
When you do a sync to an Exchange folder via the Outlook REST API, you pass it a sync token. In response, the API returns a new sync token and a set of changes. And the client is expected to send the new token back with their next sync request.
With most systems that support sync, using a stale sync token (i.e. one that has been sent to the server once) in a subsequent request will generally just succeed with no problems. And Exchange appears to work like that... for the first 999,999 times you do it. On the 1,000,000th time (and each time thereafter), you get ErrorMessagePerFolderCountReceiveQuotaExceeded. This is (I think) because Exchange keeps track of each token that it's given out and updates the token in its store each time it's used for sync. If a client uses a stale token, Exchange views it as a new client and adds that stale token as a new entry in its list of active tokens. That active token list can have at most 1,000,000 entries. ErrorMessagePerFolderCountReceiveQuotaExceeded is the cryptic error indicating that Exchange's active token list has overflowed.
I'm seeing a 403 "Access to the webpage was denied" error on one specific file being accessed via the Drive SDK. It was working earlier, the app permissions are set correctly, and we're having success with other files using different tokens against the same app.
We're getting the downloadUrl from the SDK successfully, then seeing the error message only after users are redirected to the downloadUrl. Because of that it's hard to track, but we've confirmed that it's working for some, but not for others — it hasn't fully stopped.
The full error text is:
Access to the webpage was denied
You are not authorized to access the webpage at [...] You may need to sign in.
HTTP Error 403 (Forbidden): The server refused to fulfill the request.
We're including the GET download and (valid) access_token parameters, all that.
My question is this: could this be related to the reported Google Drive outage that's currently happening, or is there some sort of throttle/limit to access of a single file over the drive API? I've never seen this behavior before, and this response isn't listed among the standard 403 responses.
I have just seen something similar. I was using a freshly acquired access token, so I don't think it's oauth related. My working theory is that the downloadUrl link was stale. When I got fresh meta data, which had a different value in downloadUrl, it worked using the same access token that had previously failed.
This is only a theory since it isn't documented anywhere, and I would actually expect 410 (or even 301) as a much more appropriate status than 403.