Reliably getting a recording ID from a conversation ID

Good evening (or morning, or whatever) :smiley:

So... if I'm reading the docs correctly, the hoops I need to jump through are:

  1. Get a conversation ID - not an issue
  2. Get a recording ID from that conversation ID by calling GET /api/v2/conversations/{conversationId}/recordings - here's where it's getting inconsistent and "interesting" - more on that later
  3. Then there was another call after that to get the actual data of the recording; I think it was just appending the recording ID on the end of the previous URL (actually using the JS SDK so I don't see much of the underlying REST stuff). Works like a charm if step 2 isn't being a flake.

So... step 2... according to the docs, this returns "Recording" (no more information given). And sometimes, that's what it does. It returns an object I can get a recording ID from... other times, it gives me... undefined? Okay..... so my next guess has been to play with it in the new API explorer tool somebody here recommended last week. This gave me... 202 Accepted?

Clearly, I'm either looking in all the wrong places for docs, or there are a few dozen subtle gotchas that my porgram is not currently anticipating. I know really old recordings get deleted, which makes sense, but none of the ones I'm trying to get are that old (most of them from a month or two ago at the latest). So.... how exactly does this thing work? I'm guessing the SDK is actually sending two XHRs under the hood, an OPTIONS and a GET or something (cuz that's the only time I've seen "202 Accepted" ever used anywhere, not to mention there is no data in API explorer when it responds like that). Here's some code, just cuz:

// The variable "recording" is a Genesys "RecordingsApi();" object, created when the page loads.
var step1 = await recording.getConversationRecordings(conversationID);
if (!step1 || !step1[0] || step1[0].fileState != 'AVAILABLE') {
    // Here it sometimes throws because step1 is mysteriously "undefined".
    // Current theory is that 202 Accepted != an object, no data in response, so #flummoxedAgain
    // Of course my logger catches it and tells me that... the question is, what's "dis-defining" my response?
    // This code is in a try-catch block, and the previous line seems to run without any errors.....
}

// Whether it gets here is about a 50/50, but I'm pasting it just for context
var step2 = recording.getConversationRecording(id, step1[2    0].id, { "formatId": "WAV", "download": true, "mediaFormats": ["WAV", "OGG_2    VORBIS", "MP3"] }); 

So....? Haha sorry, this is one of those annoying consistency problems that always leaves me guessing at any random thing that might potentially lead to a whiff of an explanation... So.... I just keep coming back to "So...?" :laughing: One of my co-workers has gotten to calling it a "Gremlin", and I kinda feel like that's the only logical explanation. :rofl: Any ideas?

Please refer to the API documentation to see all documented responses: GET /api/v2/conversations/{conversationId}/recordings. 200 and 202 are both expected responses. You'll get a 202 if the recording is transcoding and not ready yet. You'll get a 200 when it is ready.

Interesting. I found where you showed me (hidden in a sneaky little show/hide button way below where I would ever think to look :laughing: ) so yeah that was my bad. I should know by now that with extensive study of the UI, more docs can magically reveal themselves if you poke around in the right places. :laughing: But all joking aside...it doesn't say what to do in that scenario. The SDK doesn't automatically wait until it's done "transcoding" (converting between i.e. wav and ogg?) so do I just keep polling it until it's done? Increasing the "maxWaitMs" or whatever didn't seem to help. Or I guess... what is the format the files are in by default (cuz then I can just use that as my formatId)? I mean if I can save on a conversion ("transcoding") step by just using mp3 or ogg or whatever you guys normally use, that could be another potential solution.

If you get a 202, wait and try again in a few seconds. The time it takes to transcode a recording is variable based on the length of the recording as well as overall system load. You can also register for v2.users.{id}.conversations.{id}.recordings before initiating the export so you can receive a notification instead of having to poll.

The SDK wraps API requests 1:1; it does not apply additional business logic outside of the documented retry handling. You still have to code the behavior leading up to the API request and what to do with the response after its received.

All recordings have to be prepared for export. Use the format that best suits your needs.

The maximum I would expect this to work is ~9 seconds. After that, you're going to hit API timeouts; you can't wait indefinitely. If you believe this parameter is not working as documented, please open a case with Genesys Cloud Care to investigate.

Oh I'm sure it is. I would never have guessed "listen for a notification using another API" from the docs, but I've seen similar behavior in other areas (wrap-up etc.). So then is it safe to assume that any time I get a 202 from an endpoint, it's a thing I need to subscribe for notifications on? It could be that is common knowledge to those more experienced with the API, and something we should all "just know" lol...

No, that is not a standard pattern; it fully depends on the endpoint. When you browse through the list of available topics, you can see if the topic is associated with usage of a particular API endpoint.

Okay, so it's just a thing to be constantly aware of, that some endpoints might require the notifications API, so if something like this happens (seemingly bizarre, no obvious explanation) it could be I have to subscribe to something and should just turn my attention down that road. Another check that could be the cause (but is not always). Good to know.

btw, thanks for taking the time to answer stuff like this. I really appreciate it. Have a great weekend. :smiley:

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.