Errors

Requests made to Facebook API can result in a number of different error responses, however there are only a handful of basic recovery tactics. The following topic describes the recovery tactics, and provides a list of error values with a map to the most common recovery tactic to use.

Error recovery tactics

Following are the common tactics for recovering from an error response when calling a Facebook API:

1. Retry the operation after waiting
   Example: code 17 implies too many user calls, and an application should pause and retry
2. Notify the user of an out-of-band action that is required
   Example: on iOS 6 a password change means that the user must update the password for the device in order to re-enable app tokens
3. Authorize/reauthorize the user
   Example: an expired token requires reauthorization of the application by the user
4. Request permissions
   Example: the user may have removed a permission for an application after having previously granted it – so the app must re-request the permission

Other cases generally reflect a bug that will require a code change on the client to fix the bug. You may think of these cases as case B, where the user should be notified of the defect and directed to update the application if an update is available.

Error codes

The following represents a common json error response resulting from a failed API Facebook API call: { "error": { "message": "Message describing the error", "type": "OAuthException", "code": 190 , "error_subcode": 460 } }

The code and error_subcode are the most relevant information in the error payload for application error recovery. Following are code and subcodes, along with common recovery tactic used and notes.

codes

For authentication related errors, the following subcodes are useful in order to properly respond to, or tell users how best to respond to an error.

subcodes

Related topics

https://developers.facebook.com/docs/oauth/errors/