Up until now, the possibility for error has been conveniently overlooked for clarity of course. But since it's likely, if not certain, that one will inevitably occur; you should be aware of the available error handling methods and codes.
The method used is determined by the value of error_format:
- "0" - Redirect eQuest (default)
- "1" - Output
- "2" - Redirect ATS
184.108.40.206 Redirect eQuest
Redirects the user to the eQuest error page. If the error is due to incorrect or lack of information passed by the client a descriptive message is shown along with the error code in decimal format. If the error is an internal and critical eQuest error, a more general page is shown.
Simply outputs the error code in decimal format as response content. This method is commonly used by ATSs that wish to completely wrap our application's response.
220.127.116.11 Redirect ATS
Redirects the user to the value of error_url and includes an error_code parameter that contains the decimal error code.
- Authentication failed. The username or password supplied is incorrect.
- The username field is empty or missing from the HTTP POST.
- The password field is empty or missing from the HTTP POST.
- The requisition_number field is empty or missing from the HTTP POST.
- The action field is empty or missing from the HTTP POST.
- The action supplied in the HTTP POST is invalid.
- The return_url field is empty or missing from the HTTP POST.
- The requisition does not exist or is inactive. This generally occurs when an action of update or delete is requested for a job that was not previously added.
- The provided job data is invalid. This should only occur during update requests, where there is no user interaction available to correct invalid values.
- The postings identified by the given IDs do not exist or are inactive.