AnsweredAssumed Answered

Usage of requestIds

Question asked by mark.rennie1 on Jun 7, 2016
Latest reply on Jun 21, 2016 by mark.rennie1



One issue we're discussing with our application's implementation of Finesse is how to correlate requests with responses.  This is particularly important for handling error scenarios in our application.


E.g. If we get a Finesse response API error when the agent attempts to go ready then there will be nothing to tell us that the notification is in response to an attempt to go ready.  We need to be able to match the notification back to the appropriate Rest API call so we can post the correct event in our application to tell the agent their ready request was unsuccessful. 

Without this we may get a API error notification like CF_RESOURCE_UNAVAILABLE but will not know what operation we were attempting when we get this failure.


From reading through the docs I was thinking we can use the requestId field to tie these together.  However I have a few questions about use of requestIds as I don't think the documentation is fully clear on this.


  • Are we expected to set the requestId header on all Rest API requests ourselves?
    • The documentation appeared to suggest this for User API requests.  However it suggests the Dialog API (as of v11) will return a unique requestId - is that without requiring us to have set this initially?
  • Is it required that this field is a unique string?  Or could we just use it to represent the request type e.g. "GO_READY", "GO_NOT_READY", "ANSWER_CALL" etc. 
    • We could then check the requestId on the API error response and we will know what failure operation event to post in our application as we would know what we were attempting to do (e.g. Login failure, Answer call failure etc).