Accessing the inbox is tricky since each email provider operates differently. Not surprisingly this lack of uniformity can cause problems. One example is how the
TEMP_DISABLED status is applied. If you’ve experienced it, you know it can be unpredictable and quite frustrating…but we’re here to help!
TEMP_DISABLED status means the Context.IO API is temporarily unable to connect to a specific email account. The issue is specific to the account and it does not mean that there’s a problem with your application or the Context.IO API.
Why does it occur?
The status is likely due to the email server being unreachable or the email service provider throttling the API. Often there are too many simultaneous connections to the email account. The amount of connections can get quite high when you consider mobile phone apps, desktop email clients, and our services combined.
Once an email account is
TEMP_DISABLED for four hours, an API request to
http://context.io/docs/2.0/accounts#get can be made to attempt to reestablish a connection. After three consecutive failed connections, the IMAP syncing of this account is completely disabled and manual intervention will be needed to bring it back.
How can I tell if my accounts are
If you make a request to this endpoint:
http://context.io/docs/2.0/accounts#get with the
status_ok parameter set to
0, it will return a list of all accounts that have sources in temporary or permanent failure.
How can I fix affected accounts?
You can attempt to fix the
TEMP_DISABLED status in two ways. Hit the endpoint at
http://context.io/docs/2.0/accounts/sources#id-post with either the
status=1 param or the
force_status_check=1 param. The difference between them is that the status param will reset the status in our records so an API request can be made by you, and the
force_status_check param will actually make a request to IMAP and try to force a connection. For more information, please review the documentation on how to modify a data source on a given account.
How can I avoid the
Even though each email provider has different reasons for throttling, we can recommend a few best practices. The first is to reduce the number of API requests to the IMAP server with an efficient and judicious design of your application. For example, if you are using the 2.0 API perhaps you can use the message header data, which is cached, instead of fetching the entire message again. You can also use WebHooks for alerts when a specific type of update has occurred. This is more efficient than periodically connecting to an account to poll for new data.
Another suggestion is to prevent too many open connections on the IMAP server. Providers throttle accounts with alot of connections to protect against robots and automated scripts, prevent abnormal bandwidth utilization, and stop other abusive activity. Gmail recommends mail clients only check email every 10 minutes. More frequent checks might receive an INVALID CREDENTIALS error which we return as
TEMP_DISABLED (see this article for more info). The logic will eventually correct itself via retries but it’s important not to open too many connections to user accounts through your application.
We hope this has provided insight into
TEMP_DISABLED and how you can avoid it in the future. If you have any questions, please leave them in the comments section or contact our support engineers. We’re always happy to schedule a call if you have technical questions!