Names of Lines when setting up new WebRTC phones

When going over the amazing well constructed "Create a phone" page I am putting together all the pieces I need for my own request.

I see I will require a value for the line name. Looking at all the other WebRTC phones we have setup, I am confused as to what to put here. All my users appear to have different values for the line names, which makes sense, but it looks like there is a random part to it?

Here is the format that I am finding on all our users right now:
6654955f414af31bca9ceb54+{org_name}.orgspan.com

Previously we have always manually created new WebRTC phones for users and this is our first time trying to automate it with an API request. As I understand it, the line is created when the phone is created. In that case I feel that first value is truly randomized? In that case can I just set the line name to be the same as the phone name, or does it need to be in that format of {value}+{org_name}.orgspan.com ?

Thank you for your time and consideration,

Update:

I was still struggling to understand what was truly required and what wasn't. Trying to build the command through the API Explorer, the body kept expanding because it would tell me that yet another field was required and eventually I end up in an error state telling me that the tempateId was a required field and could not be empty, regardless of the fact that I had the value in the body.

Here was the "final" product when trying to build in the API Explorer when I hit that last error:

More searching later, I came across this post here where they had a much cleaner cut down JSON and it worked just fine!

So there are a few things I saw and learned in this whole process that might help someone else in the future.

  • There are some items in the API Explorer that say they are required, but they are not. Here are the fields we are using and it successfully creates a new phone.

    • site - id: string
    • phoneBaseSettings - id: string
    • name: "string"
    • lines - lineBaseSettings - id: string
    • webRtcUser: id: string (you may not need this)
  • The API Explorer says that Line, Name is required.
    2024-07-02 12_29_18-Create a phone

    • I feel that is incorrect. The line name IS dynamically set when the line is created. The line is created when the phone is created. This is why you just need to supply the lineBaseSettings id.
  • I have noticed that this did not assign the phone to the user as their default phone. I assume you will have to run an PUT command after the phone is created to have that updated.

Hi @DeeQ I have redirected this question to the phones API folks, I will get back as soon as I have a response from them

1 Like

Hi @DeeQ

  1. It seems that line name will be automatically populated for webRTC phones only. For other types of phones, we will have to provide the name.
  2. At present there is no way to assign a phone to a user when the phone is being created.
1 Like

As a closure to this thread, I have the rest of the information I have discovered. This might seem obvious to others, but to the more green users learning Genesys API's it might not be, as it wasn't for me. Should some other individual require it moving forwards.

The process of creating and assigning a phone is done in two parts.

  1. Create the Phone

    • If this is a physical phone, you do need to supply it a name. WebRTC Phones do not require it as previously covered.
    • You need to include the webRtcUser information. You would think that this data would assign the phone to the user, but it's not. It's used for reference in the next step.
      • This includes both the webRtcUser ID and Name
  2. Assign the Phone

    • Lookup the station ID for the new WebRTC phone. This ID was created automatically when you setup the phone. In order to find it, perform a GET to /api/v2/stations with a query of "webRtcUserId": {userID} to filter to the phone station needed.
    • Take that station ID and use it in your PUT request to /api/v2/users/{userID}/station/defaultstation/{stationID}

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