Skip to main content
Skip table of contents

Working with Errors

HTTP Status Codes

REST API methods return three-digit HTTP "status codes" to indicate the outcome of a request. See RFC 2616 Section 10 for details about HTTP Status Codes. By convention, codes in the range 200-299 indicate success. Codes in the range 400-499 indicate an error in the request. Codes in the range 500-599 indicate a server-side error.

The HTTP status codes returned by LightWave Server when calling user-defined API methods may come from one of two sources:

  • a response mapping in the user-defined API method
  • from LightWave Server itself, in the case that the user-defined API method could not be executed

In the case of a response mapping, it's up to the API designer (developer) to decide which HTTP status codes and message content should be returned based upon the response code from the server application. 

In the case of status codes returned by LightWave Server itself, the following may be returned:

400-level errors are returned when there is a problem with the request. These are generally due to a client application programming error.
400Bad RequestThe request is malformed. For example, required query parameters missing, body content missing or invalid JSON, etc. Also, a if bad transaction id is supplied, bad Pathway dialog id, etc.
401UnauthorizedNo HTTP Authentication header was supplied and the Service has an Access Control Policy that is restricted to a particular user or group.
403ForbiddenAn HTTP Authentication header was supplied, but the Service's Access Control Policy does not permit the authenticated user (due to user, group or source IP restrictions).
404Not FoundThe supplied URI (the 'path') does not match any path belonging to any deployed Service (on the TCP/IP port).
405Method Not AllowedThe supplied URI is valid, but the requested method (GET, POST, PUT, etc.) is not defined for the URI.
500-level codes are returned for errors that are not due to the content of the request itself -- there is nothing the client application can do to fix the problem. There are typically server configuration errors.
500Internal Server ErrorAny error that prevents LightWave from communicating with your server application (e.g., a Pathsend or Guardian error). Other causes include license expiration.
501Not ImplementedA method other than OPTIONS, GET, POST, PUT or DELETE was attempted.

HTTP Headers

In addition to the status code, error responses generated by LightWave Server include error details within the following HTTP headers:

HTTP HeaderDescription
lw-error-sourceThe source of the error; "lightwave", "nsk", or "pathway"
lw-error-codeThe error number within the 'error source'
lw-error-subcodeAdditional detail for 'error code', if applicable
lw-error-textA textual description of the error

Error responses generated by LightWave Server have no body content, i.e. content-length = 0. Error responses returned from user-defined API methods do not include 'lw-error' headers and may include body content.

Interpreting lw-error-code

9013deserialization errorError converting the request JSON body content to server IPM format
9014serialization errorError converting the server response IPM content to JSON format
9016API compiler errorError in API definition
nskGuardian File System Error; see the HPE Guardian Procedure Errors and Messages Manualn/a
pathwayPathsend Error; see "Pathsend Errors" in the HPE NonStop TS/MP 2.5 Pathsend and Server Programming ManualGuardian File System Error, when applicable

Suppressing HTTP Status Codes

Some client frameworks will not return response content if the HTTP Status Code is not 200. To overcome this, use the lw-suppress-status parameter when invoking the request. When this parameter is present, the response status code will be 200 regardless of the outcome of the operation. The actual status information is provided in the response lw-http-status and lw-http-reason parameters. When an error occurs, additional error detail is returned in the response lw-error parameter group.

The following examples show how the lw-suppress-status parameter alters the response for an HTTP "400 Bad Request" error returned by the Process API when the target server does not exist. In this example, if lw-suppress-status were not used, the returned HTTP status code would be 400.


POST /lightwave/api/v1/transaction/not-a-transaction-id HTTP/1.1
lw-suppress-status: 1
Content-Length: 0


HTTP/1.1 200 OK
lw-http-status: 400
lw-http-reason: Bad Request
lw-error-source: nsk
lw-error-code: 78
lw-error-subcode: 0
lw-error-message: Transaction identifier is invalid or obsolete.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.