Glia provides a robust set of APIs that allow for two-way data integrations with the Glia platform via secure REST API calls. This documentation provides information and examples for each of the available APIs delivered by Glia. These APIs allow clients to create integrations for areas of the platform such as Visitors, Operators, Engagements, Statistics, and Single Sign On. The APIs allow clients to keep Glia synchronized with their systems of record with minimal development effort.
This documentation is for Glia API v1 and includes example responses for each API method illustrating the attributes returned by that method. If you have any issues, requests or concerns with the documentation please contact the Glia Service Desk.
The current API version is v1 and it must be explicitly requested via the Accept
header.
Accept: application/vnd.salemove.v1+json
All API access is over HTTPS and accessed from the https://api.salemove.com
endpoint. All data is sent and received as JSON
. The only supported cryptographic protocol is TLS 1.2.
Blank fields are included as null
instead of being omitted.
HTTP/1.1 200 OKDate: Thu, 29 Jan 2015 11:44:37 GMTStatus: 200 OKConnection: closeContent-Type: text/html;charset=utf-8Access-Control-Allow-Origin: https://salemove.comAccess-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, PATCHAccess-Control-Allow-Headers: *, Content-Type, Accept, AUTHORIZATION, Cache-Control, X-Salemove-Visit-Session-IdAccess-Control-Allow-Credentials: trueAccess-Control-Max-Age: 1728000Access-Control-Expose-Headers: Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, PragmaContent-Length: 0X-XSS-Protection: 1; mode=blockX-Content-Type-Options: nosniffX-Frame-Options: SAMEORIGIN
All timestamps use the ISO 8601
format.
YYYY-MM-DDTHH:MM:SSZ
Many API methods take optional parameters. For GET
requests, any parameters not specified as part of the path can be passed as an HTTP
query string parameter. For POST
, PATCH
, PUT
, and DELETE
requests, parameters not included in the URL should be encoded as JSON
with a content-type
of application/json
.
If the request is malformed, then the server responds with an error. The response contains a description of the error. In general, the response includes two attributes: namely, error
which contains a short description of the error encountered; and a debug_message
which contains a more detailed explanation of the error.
HTTP/1.1 400 Bad Request
[{"error": "BadRequest","message": "Invalid api version used","debug_message": "Invalid api version used. Make sure you set the 'Accept' header with API version e.g. 'application/vnd.salemove.v1+json'"}]
Where possible, the Glia APIs strive to use appropriate HTTP verbs for each action.
Verbs | Description |
| Can be issued against any resource to get just the HTTP header info. |
| Used for retrieving resources. |
| Used for creating resources. |
| Used for updating resources with partial JSON data. For instance, an Issue resource has |
| Used for replacing resources or collections. For |
| Used for deleting resources. |
Along with the request, the following headers must be sent:
Header | Description |
| Specifies the response format and the API version. See Accept for more information. |
| Token for authorization. See Authorization for more information. |
curl --request GET \--header "Authorization: Bearer $access_token" \--header "Accept: application/vnd.salemove.v1+json" \"https://api.salemove.com/operators"
$.ajax({type: 'GET',url: 'https://api.salemove.com/engagements',headers: {'Accept': 'application/vnd.salemove.v1+json','Authorization': `Bearer ${access_token}`},success: function(response){ajaxResponse = response;}});
Each operator or other privileged user such as super manager, has an API token (e.g. wSdzZbnJfPEKOBs_D6Fwjw
). This API token is provided by Glia success manager, it has a long lifetime and it is only used to obtain an access token. Access token is then used for the actual REST API calls and for security reasons has a short lifetime (one hour).
To obtain the access token:
curl --request POST \--header "Accept: application/vnd.salemove.v1+json" \--header "Content-Type: application/json" \--data '{"api_token": "wSdzZbnJfPEKOBs_D6Fwjw"}' \"https://api.salemove.com/operator_authentication/tokens"
Response:
{"token":"eyJhbGciOi<truncated>"}
The obtained access token can be then used to send the actual requests to Glia REST API, for example:
curl --request GET \--header "Authorization: Bearer eyJhbGciOi<truncated>" \--header "Accept: application/vnd.salemove.v1+json" \"https://api.salemove.com/operators?site_ids[]=$site_id&include_offline=false"
Authorization of REST API calls by visitors, follows similar concept to operators. Each site has an application token (e.g. 6YpHYDxZjj8uSjTy
). This application token is provided by Glia success manager and it has a long life time. The application token is used to create a visitor, and as part of it, also return the access token for this visitor. The access token is then used for the actual REST API calls and for security reasons has a short lifetime.
To create a visitor and obtain the access token, see Create Visitor.
To renew the access token of an existing visitor, see Renew Visitor Access Token.
Once the visitor access token is obtained, it can be used to send the actual requests to Glia REST API, for example:
curl --request GET \--header "Authorization: Bearer eyJ0eXAiOi<truncated>" \--header "Accept: application/vnd.salemove.v1+json" \"https://api.salemove.com/sites/$site_id/visitors/$visitor_id"
When Glia is integrated into a web page, the visitor is created implicitly by Glia integration script. In that case one should use the Visitor JS SDK to perform any actions as the visitor on the web page. The JS SDK takes care of handling the access token necessary for the underlying REST API calls.
Unless otherwise specified, all endpoints require Accept: application/vnd.salemove.v1+json
header.
Value | Description |
| Specifies the API version for JSON response. For the version |
| Specifies the returned content type. Possible values for |
The API supports Cross Origin Resource Sharing (CORS) for AJAX requests from any origin. More information about CORS is available in the CORS W3C Recommendation and in the intro to the HTML 5 Security Guide.
GET /operators
Generates the output
{"next_page": "http://api.salemove.com/operators?page=2","last_page": "http://api.salemove.com/operators?page=3","collection": [{"href": "http://api.salemove.com/operators/f42811bc-8519-4d33-bbb1-36d4555ecb0a","attribute": "value","...": "..."},{"href": "http://api.salemove.com/operators/c8b52f0b-ad05-4c71-8c98-5056f07c4d1a","attribute": "value","...": "..."},]}
Some requests that return a large collection of items are paginated. The following parameters are supported:
Parameter | Type | Description |
| Number | Requests a specific page. |
| Number | Sets the quantity of items returned with each page.
|
| String | Supported values are |
GET /operators?page=2
The responses for collections that are paginated include an attribute next_page
that points to the next page of items for the collection. In addition, the response includes a last_page
attribute that points to the last page of the collection.