Before you begin working with ECE API it is important to understand some of its key characteristics.
ECE REST APIs are stateless. All the necessary information to process a request is contained in the request itself. No context information is stored on the server to process the request. Statelessness improves the API performance, and allows better scalability for the application.
The REST architecture of ECE APIs allows the existence of intermediaries such as gateways, proxies, or load balancers between the client and the server to facilitate improved scalability and to enforce security policies.
ECE REST API supports both XML and JSON as the data format for requests and responses. The default format is XML.
Use the HTTP header Accept:application/json to select JSON or Accept:application/xml to select XML.
ECE REST API supports session based authentication. To learn more about authentication refer Understanding Authentication.
In order to improve performance, ECE API allows the use of compression on responses.
Accept-Encoding:gzip in a request. The response is compressed if a client specifies this header in the request, and the response includes HTTP header Content-Encoding:gzip to indicate response compressionECE API responses are optimized to minimize the network traffic. As a result, the response includes only a pre-defined set of attributes; the other parts of the resource are not included in the response unless explicitly requested. You can request additional attributes of a resource by using the $attribute query parameter.
Use the $attribute query parameter to specify a comma-separated list of additional attributes that you want in the response. For example, appending $attributes=keywords,summary to an Article URI's request will result in inclusion of keywords and summary for the requested article. You can also use $attributes=all, a special construct, to request all the attributes of a resource.
All public interaction APIs that been released till now and that we will be releasing as part of the test. Test is run on setup with base data.
| Object | Count | Object | Count |
|---|---|---|---|
| Case | 590925 | Activity | 1030019 |
| Chat Activity | 1638 | Email Activity | 1028119 |
| Department | 5 | Customers - Individual | 51770 |
| Customers - Group | 0 | Customers - Corporate | 0 |
| Email Alias | 24 | Chat Entry Point | 33 |
| Queue | 308 | Purge Job | 3 |
| Email Attachment | 118686 | Macro | 232 |
| Message | 51 | Notes | 2321 |
| Language in use | 1 | Articles | 98631 |
| Articles with Attachments | 16210 | Email Inbound Workflow | 32 |
| Outbound Workflow | 1 | Alarm Workflow | 7 |
All APIs except the ones listed below had response times above 500 ms but were within an average of 1 second.
| API Name | Response Time (ms) |
|---|---|
| Create Individual Customer | 523 |
| Post Inbound Activity | 1270 |
| Search Case by Work Status | 556 |
| Search Customer by Custom Attribute | 750 |
| Change Customer of Activity | 705 |
If APIs are run on top of full load, a 20% increase in CPU usage is expected compared to standard load tests without API calls.
The load test was performed on Interaction/Agent Console APIs. For Admin APIs (e.g., Get Agent Details or Get Queue Details), the frequency of API calls should not match that of interaction APIs.
Admin APIs related to agent/queue configuration rely on real-time AWDB data. Configuration changes may reset permissions, affecting AWDB response times. Therefore, these APIs should be triggered:
ECE REST API supports Cross-origin resource sharing (CORS). CORS is a mechanism that allows resources (e.g. fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated.
You can configure a whitelist of the origins for ECE REST API from the ECE Administration Console.
The API currently covers the following areas: