Response body

All response bodies contain text of type application/json encoded in UTF-8. For requests with nontrivial responses, this is a JSON object encoding the requested detail. For requests that do not require a response (most actions), this is the single element null. If the request was not successful, the JSON in the body is usually an object containing the two fields error_code and error_message. Some fundamental errors (malformed requests, for example) have an empty response body.

The response also echoes all elements of the request that are not otherwise used. This can be used to distinguish different requests or streams of requests that arrive out of order.

HTTP header response codes

If you are connecting over IP, the response header includes one of the following codes:

  • 200 OK—Success — This does not necessarily mean that the action was valid and was performed; it was not determined to be invalid by the endpoint
  • 400 Bad Request — Request was malformed in some way. Includes problems like POSTing invalid JSON and offering invalid arguments to actions
  • 405 Method Not Allowed— Unsupported HTTP method. Only GET, HEAD, POST and OPTIONS are allowed
  • 409 Conflict — The request is not valid in the current state. For example, trying to hang up a call when not in a call. This may not be returned in all possible cases, because it has to be determined by the endpoint
  • 413 Request Entity Too Large— The POST request body is more than 64 kilobytes; a valid request should not exceed this limit
  • 414 Request-URI Too Long— The GET or HEAD query string is more than 64 kilobytes; a valid request should not exceed this limit
  • 500 Internal Server Error— Contact Teamline Support with details of the request
  • 503 Service Unavailable— There are too many outstanding requests against this server

Example responses using IP connection

For example, if the endpoint receives the request:


It might send the response:


Which indicates success in that the endpoint has received the request and returned a response. For actions, this is usually returned immediately.

State updates work similarly, though may be returned at some point in future. If the endpoint receives a request like:


The endpoint does not send a response until the call state updates. If an incoming call arrives, this is updated and the endpoint sends the response:


And an example of a failing request:


With response:

 "error_code" : 7,
 "error_message" : "Invalid state for action hold: no usable default call for action."
Was this information helpful?