Support Resources

LucidWorks Forum
KnowledgeBase

LucidWorks Search v2.5

PDF Versions

Older Versions

LucidWorks 2.1
LucidWorks 2.0
LucidWorks 1.8

This is the documentation for the LucidWorks Search v2.5, the latest release. Go here for LucidWorks 2.1.

Skip to end of metadata
Go to start of metadata

In an ideal world, all of your programming calls will work perfectly. Unfortunately, we do not live in an ideal world, and occasionally you will need to deal with error messages. LucidWorks returns errors as JSON maps that provide all of the information you need to determine the problem. They are in the following format:

{
   "http_status_name":{string},
   "http_status_code":{integer},
   "errors":[
      {
         "message":{string},
         "key":{string}
      },
      ...
   ]
}

These values correspond to the following information:

http_status_name: The name of the status code.

http_status_code: The integer status code that classifies the error. These integer codes correspond to standard HTTP response codes. For example, if you reference an object that does not exist, the error code will be "404", the traditional "Not Found" response. For more information, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

errors: This object contains more detailed information on the reasons for the error status, including:

message: A human-readable error message explaining the problem.

key: The input key that the message pertains to. This may be an empty string if the error does not correspond to a submitted key.

Example
{
   "http_status_name":"Unprocessable Entity",
   "http_status_code":422
   "errors":[
      {
         "message":"Unknown type:bad_type",
         "key":"type"
      },
      {
         "message":"start_time could not be parsed as a date",
         "key":"start_time"
      }
   ]
}

Note that more than one error may be passed in an error response.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.