Troubleshooting Sjerlok Case API

Sjerlok Case API FAQ

Testing, Use cases, and Examples

In order to manually test the API, you can make use of the Postman application or directly the CLI with the cURL command.

In order to successfully execute the command, you must replace the tags with relevant data as follows:

• <token>: This is the authorization token in order to authenticate the user making the request.

• <data in JSON format>: the actual data for the case containing the fields described above in the Description of request body data section. More examples on how the data structure looks like can be found below with the use cases

• <sjerlok-server>: This is the target Sjerlok application. It can be the production environment admin.sjerlok.com , the acceptance acc.sjerlok.com, or even the local environment

Successfully creating a case with all the necessary fields provided.

Payload example:

The response will be:

This will result in the creation of a case in the Sjerlok application with the provided data. The HTTP status of the response will be 200.

Updating the values of the case’s overwritable fields

Payload example:

The result will be:

First of all, please keep in mind that the only fields that are available to be updated are the following:

Any other value provided for the other fields will be ingored and the inital value will be kept. Also please pay attention that when wanting to update a case values the same VIN and License plate have to be used in order to crrectly identify the targeted case. Failing so will result in the creation of a new case

Sending a request with an empty payload will result in an error detailing the mandatory fields

Payload example:

The response will be:

The response will contain all the mandatory first level fields that must be provided in order to process the information. In this case disappear_date, case_number, object_data as per the table above detailing all the available fields. Note that in this case, the HTTP status of the response will be 400.

Sending a request with an invalid model name will create the case and send an email with the incorrect value

Payload example:

The response will be:

This will create a case in the Sjerlok application, but it will not contain the model information since it was not possible to identify it in our internal data structure containing these kinds of information related to aspects like make, model, version, etc.

Due to this, the application will send an email noticing about the incorrect value provided, but it will also store this information in the case notes such that it can be further investigated manually.

Overlooking the category field from the request will create the case and try to infer the value of category

Payload example:

The response will be:

The request will create a case, and the case object will have a category value assigned to it. This is due to the fact that the category can be inferred based on the other fields of the object_data, namely the make and model fields. This is done using our hierarchical internal structure for the value of these fields and thus determine that the BMW values is under the Cars category, automatically filling this missing information.

Overlooking the category field, and the model field from the request, but the make field has enough information to infer the model. This will, in return, be used to infer the category as well when the case is created.

Payload example:

The response will be:

The request will result in the creation of a case due to several factors. As per the previous use case, using our hierarchical internal structure, it will identify based on the value of the make field that the value for the model field is in fact X1. Next, using these two values, it will proceed to infer the category as it does in the previously described use case.

The company of the case will be set as the current company based on the token used to authenticate the requesting user

Payload example:

The response will be:

This will create the case in the Sjerlok application and will automatically fill the information about the case company based oh the authentication token used to authorize the request. The company will be the current/active company set for the user at the moment that the request is sent.

Sending a request overlooking both VIN, and License Place fields for the Case Object will result in an error response

Payload example:

The response will be:

The fields VIN, and License plate are required in order to uniquely identify the cases in our system. Furthermore, these are required in order to identify the case when the user wants to update some of its values. In an ideal world, it is prefed for both the fields to be present in the request, although one of them woudl be enough.

Therefore, skiping both of these fields will result in an error response.

When only one of them is skipped, it will result in creating a case, but the missing information will not be present in the case’s details.

Sending a request and overlooking the make field for the Case Object will result in an error response

Payload example:

The response will be:

Skiping the make field from the object_data will result in an error due to the fact that the object can not be placed inside out internal hierarchical internal structure.