3.7. Error Handling

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.

3.7.1 Methods

The method used is determined by the value of error_format:

• "0" - Redirect eQuest (default)
• "1" - Output
• "2" - Redirect ATS

3.7.1.1 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.

3.7.1.2 Output

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.

3.7.1.3 Redirect ATS

Redirects the user to the value of error_url and includes an error_code parameter that contains the decimal error code.

3.7.2 Codes

16390

Authentication failed. The username or password supplied is incorrect.

16386

The username field is empty or missing from the HTTP POST.

16387

The password field is empty or missing from the HTTP POST.

16391

The requisition_number field is empty or missing from the HTTP POST.

16392

The action field is empty or missing from the HTTP POST.

16393

The action supplied in the HTTP POST is invalid.

16396

The return_url field is empty or missing from the HTTP POST.

16398

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.

16406

The provided job data is invalid. This should only occur during update requests, where there is no user interaction available to correct invalid values.

16399

The postings identified by the given IDs do not exist or are inactive.