The API is designed to fail gracefully providing a predictable and reliable way to handle errors. As a precaution, we recommend checking types and integrity before sending data as a way to minimize the interaction with the API, but in the event you have a problem the API supplies debugging information.
The standard API error response looks like this:
<?xml version='1.0' encoding='UTF-8'?> <methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><i4>6</i4></value> </member> <member> <name>faultString</name> <value>error reason</value> </member> </struct> </value> </fault> </methodResponse>
You can immediately recognize there is a problem because the only element in <methodResponse> is <fault>. You can parse this response for the fault code value if you're interacting with Infusionsoft support. For a customer facing error, You can parse out the value of faultString for the reason.
As a developer you've probably noticed that the ubiquity of this response lends itself to creating an error handling class for their project.