Error Documentation

Comments

4 comments

  • Avatar
    Stephen Doyle

    Hi Brian.

    We don't currently have a strict or formal set of possible error responses for different operations, though we generally use standard HTTP status codes to indicate the high-level reason of the problem as many other services do (e.g. 400 - problem with the request, 404 - not found, etc). 

    There are some more specific examples in our Admin API documentation here: https://cloudinary.com/documentation/admin_api#error_handling

    And in our provisioning API documentation here: https://cloudinary.com/documentation/provisioning_api#error_handling

    In addition, when making API calls that fail, the response will include an error text, and when accessing an asset's delivery URL that fails, we return an error text in the x-cld-error HTTP header of the response, which can be used to log and display the reason that the asset didn't load

    Some of our client SDKs wrap common errors in Exception classes based on the type of error, so you can use the code for those SDKs as further examples of what some of the more common errors are that you may encounter

    If you encounter an error where the text isn't clear about what happened, or it's not clear how to resolve it, you can always open a request for our support team via this site ("Submit a request" on the top of the support homepage) and we'll be happy to assist

    Thanks,

    Stephen

    0
    Comment actions Permalink
  • Avatar
    Brian Qian

    Hi Stephen,

    In the context of the Upload Widget API the only error response I can force looks like {status: "error", statusText: "error"} which isn't documented anywhere and has no error codes. Can I assume that for the widget the shape is completely different from the Admin API and that no status codes are returned?

    Is there any way I can force different errors that have more meaningful information?

    0
    Comment actions Permalink
  • Avatar
    Silly sing

    Thanks Stephen for detailed answer.

    0
    Comment actions Permalink
  • Avatar
    Stephen Doyle

    Hi Brian,

    The events sent by the Upload Widget should include the details of the error that was returned to the widget by our Upload API, though the text is included in that statusText property as you said and I don't believe it includes the HTTP status code returned by the API (though for using the upload API with unsigned uploads, 400 and 200 are the most likely response codes by a very large margin)

    If you see events raised that don't include the details of what the actual error was, may I ask for an example I can check?

     

    0
    Comment actions Permalink

Please sign in to leave a comment.