While using the java REST remote API, when using some operations that generate an exception on the server, the server returns status code 500 and writes down a string that represents the error that happened on the server.

When the remote API encounters that situation, it translates that result into a RuntimeException in which it uses that string as the parameter.

The problem here is that RuntimeException can be too many things and not necessarily caused by jBPM at all! It can be a merely ArrayIndexOutOfBounds, NullPointerException, and so on, and so forth.
If I try to prevent the user from getting this exception I'm catching all RuntimeExceptions, the ones form jBPM and the ones from other sources. I may write them to a log but still... That log would need motorization and filtering to make sure that the right actions are made.
Besides, as far as I can remember, Java never throws the RuntimeException itself, it always throws an exception that extends RuntimeException when a runtime exception happens.

To solve that issue, my suggestion is, as a temporary solution, to make a class that extends RuntimeException that represents that an exception that happened on the server (for example, RemoteAPIException) that is treated, in the remote API, as RuntimeException currently is. This way developers can, programmatically, distinguish a java (or any other library or framework's) RuntimeException from the jBPM one.