mayliwk | 2016-06-24 12:24:25 UTC | #1
I am currently testing the API in hopes to build a dashboard. One of the calls I have been trying is the getCallHistory call. This however is not bringing any records back. We have been testing the system for a few weeks and still no data. <img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/868803f07e6cbe4f5a568c9ec907752fa719f249.png" width="690" height="462">
Any help would be greatly appreciated.
tim.smith | 2016-06-24 14:57:09 UTC | #2
It appears that you're passing in 100 for the page number. Unless you have 10,000+ calls for that 2 day range, you're not going to get any results for page 100 when you page size is 100. You can pass in Nothing for the pageNumber and pageSize parameters to use the defaults, 1 and 25 respectively. Otherwise, always start with page 1 with any page size.
mayliwk | 2016-06-24 15:37:51 UTC | #3
Thanks. I made the change and still have no results.
<img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/33bd4eeb7a0873f31e7ca3830927cc6a7009ce91.png" width="690" height="319">
tim.smith | 2016-06-24 17:03:15 UTC | #4
Are you sure that the logged in user has call history for that period? If you specify Nothing for interval, it will default to looking at the last 28 days. Try that and see if you get anything. Also, try making the request to GET /api/v2/conversations/calls/history manually (i.e. curl or postman and see if you get results. Doing the request manually will determine if anything with the SDK is causing an issue.
FWIW, if I query for a period with no history, that's what my response looks like as well.
tim.smith | 2016-06-24 17:11:17 UTC | #5
Just an FYI, I noticed a bug in the API from your screenshots and confirmed with my testing. The self/first/last URI properties have incorrect URI values; they leave off "/history". I've reported the bug and it should be a quick fix. As a workaround if you need to get paged results, just use pageNumber and pageCount to determine the page you want and step your way through the paged results.
mayliwk | 2016-06-24 18:32:25 UTC | #6
So the GetCallsHistory only returns data for the logged in user? How would it work if you used the client credentials grant?
tim.smith | 2016-06-24 18:39:07 UTC | #7
It wouldn't work because client credentials do not represent a user. If you're trying to get historical conversation information for a user other than the logged in user, or when using client credentials, you will need to use the Analytics APIs.
mayliwk | 2016-06-27 13:23:27 UTC | #8
Thanks.
If I use "PostConversationsDetailsQuery", with an empty body, will that bring back a complete call history?
anon66512198 | 2016-06-27 17:10:28 UTC | #9
Yes, you'll need to specify an interval at minimum when you map the API call. You can reference the Conversation Detail Query page for example syntax.
tim.smith | 2016-06-27 19:59:00 UTC | #10
It's not everything. If you don't specify a range, it defaults to the previous 28 days.
mayliwk | 2016-06-28 15:35:04 UTC | #11
I was working with this today and noticed some weird results. I am trying to use the paging feature and I am running into 2 issues.
first, the data coming back is time stamped in the future. <img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/54f2ee58057f0adef1cf45e3a3bc69b76c409671.png" width="690" height="402">
second, I am unable to get to the end of the data with paging. It just keeps looping. I have built a loop that increments the page until the count returned is not the same as the page size (25) ` intPage += 1 page = New PagingSpec(25, intPage) convBody = New ConversationQuery(Interval:=strInterval, Paging:=page) conversations = analytics.PostConversationsDetailsQuery(convBody)`
Thanks for the help.
tim.smith | 2016-06-28 15:59:33 UTC | #12
the data coming back is time stamped in the future.
Can you make the requests using postman so you can see the timestamp in the raw body? It would be useful to know if the timestamp is coming back incorrectly from the server or if the SDK is parsing it incorrectly.
I am unable to get to the end of the data with paging. It just keeps looping.
I have built a loop that increments the page until the count returned is not the same as the page size (25)
That sounds like paging is working since you get to the final page at some point (page size < 25). Take a look at the docs for API Paging. If you are seeing behavior different than outlined there, let me know.
mayliwk | 2016-06-28 17:07:38 UTC | #13
I ran this call against postman. The results are the same. I asked one of our customer care reps for average daily calls and I was told around 1000. I can set the page size = 100 along with the page number = 200 and still bring back records. The time stamps for these are in the future as well. <img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/41cbbd11e5ca557ee4434abe6569e14b6af81350.png" width="572" height="500"> <img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/d14e14c44d1f8dcc6c7584bf5c5dbdc8879b2cc9.png" width="336" height="500">
mayliwk | 2016-06-28 17:08:58 UTC | #14
What time zone is used for this?
tim.smith | 2016-06-28 18:37:36 UTC | #15
What time zone is used for this?
The timestamps are ISO 6801. The values have a Z at the end, so it's UTC. The property should be a DateTime in the SDK and I would expect the Kind property to be set to UTC to indicate this.
I can set the page size = 100 along with the page number = 200 and still bring back records.
That means there are still results. From my testing, if I exceed the number of results, I get back a completely empty result set of {}.
I've noticed that there's a problem with the object returned by POST /api/v2/analytics/conversations/details/query, however. The resource allows you to specify paging values, and it appears to page the results correctly, but the response is missing the standard paging properties that tell you what page you're on, how many results there are, and links for the next pages. I'll investigate that and get an issue opened for it.
In the meantime, you'll have to work around this by starting at page 0 and incrementing by 1 and comparing the result set. You'll know you've reached the end when you get an empty result set. You can verify that the IDs from the result sets don't match/overlap for added verification.
mayliwk | 2016-06-28 19:03:14 UTC | #16
I found the end. At 100 items per page, the end was on page 532. That would give us 53000+ conversations and we just went live with this tool this morning and we do less than a 1000 calls a day. Can you help understand what is going on?
Thanks
tim.smith | 2016-06-28 21:05:02 UTC | #17
I don't have access to any of your data, but you can compare the results from your API queries with the output of the standard reports as long as you use the same filter criteria (users, interval, etc). The most relevant report to compare with this API resource is probably the Interaction Details Report.
A couple ideas as to why you might see more results than you expect is because not all calls make it to agents. Calls that were just in the IVR will also show up using this API resource. You'll also see internal calls if internal people are calling each other. Using a segment filter on purpose and other segment properties can refine the results to calls that had a user involved, external calls, IVR calls, etc.
tim.smith | 2016-06-28 21:21:54 UTC | #18
I have filed API-1684 to investigate the paging issues with this resource.
tim.smith | 2016-06-28 21:42:32 UTC | #19
I've also found API-4096 that is pending release to production. There is an issue with paging with this resource where the offset is not being applied correctly. If you request page 0, take note of the second conversation. It will be the first result on page 1. That is probably the biggest cause of the excessive number of results you're seeing.
system | 2017-08-28 19:25:02 UTC | #20
This post was migrated from the old Developer Forum.
ref: 98