Cisco Webex Meetings API Updates Overview (API 41)

For more info on XML API 39 and XML API 11, see the Cisco Webex Meetings XML API Updates Overview (XML API 39 and Earlier).

For more info on XML API 40, see the Cisco Webex Meetings XML API Updates Overview (XML API 40 and Later).

For updates for XML API 11 SP9 and earlier, go to Cisco DevNet.

XML API 41.12.0 Updates

Click here to download the XML API 41.12.0 schema.

XMLAPI will block Webex Events (Classic) schedule and editing according to site config item of EnableClassicEvent that is false

Impacted APIs and Schema changes

In site administration configuration page, if Enable classic Event checkbox is false, this site won't support Webex Events (classic) meetings any more.

If the Enable classicEvent checkbox is false, you call these APIs to operate Webex Events (classic) meeting:

CreateEvent, SetEvent, GetEvent, GetSessionInfo, LstsummaryEvent, LstrecordedEvent, LstsummaryProgram, UploadEventImage

The API will response new exception 010106 The classic Event has been disabled.

Schema changes

No schema changes.

API request and response example

CreateEvent API request and response

Request of CreateEvent

<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent">
<accessControl>
<sessionPassword>XXXXXXXX</sessionPassword>
</accessControl>
<metaData>
<sessionName>XMLAPI EC Testing</sessionName>
</metaData>
<schedule>
<startDate>07/17/2021 01:29:15</startDate>
<openTime>15</openTime>
</schedule>
</bodyContent>
</body>
</serv:message>

Response of CreateEvent

<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>FAILURE</serv:result>
<serv:reason>The classic Event has been disabled.</serv:reason>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
<serv:exceptionID>010106</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>

CreateEvent3.1.3 Affect APIs:

• SetEvent GetEvent

• GetSessionInfo

• LstsummaryEvent

• LstrecordedEvent

• LstsummaryProgram

• UploadEventImage

XMLAPI LstMeetingType will responsed to new element of subProductCodePrefix

Impacted APIs

Current the API LstMeetingType response element of productionCodePrefix: PRO, AUO, and others which are Webex predefined meet type prefix.

After this new enhancement, the API will response new element of subProdctCodePrefix:PRO1, PRO2, etc. which can be customized meet type prefix.

Schema changes on API: LstMeetingType

It will response new element: subProdctCodePrefix

API request and response example

LstMeetingType API request & response

Request of LstMeetingType

<bodyContent xsi:type="java:com.webex.service.binding.meetingtype.LstMeetingType">
<meetingTypeID>13810</meetingTypeID>
</bodyContent>
</body>
</serv:message>

Response of LstMeetingType

<serv:body>
<serv:bodyContent xsi:type="mtgtype:lstMeetingTypeResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<mtgtype:matchingRecords>
<serv:total>1</serv:total>
<serv:returned>1</serv:returned>
<serv:startFrom>1</serv:startFrom>
</mtgtype:matchingRecords>
<mtgtype:meetingType>
<mtgtype:productCodePrefix>PRO</mtgtype:productCodePrefix>
<mtgtype:subProductCodePrefix>PRO3</mtgtype:subProductCodePrefix> //New element for customized meeting type
<mtgtype:active>ACTIVATED</mtgtype:active>
<mtgtype:name>Cus_Chat_Closed</mtgtype:name>
<mtgtype:displayName>Cus_Chat_Closed</mtgtype:displayName>

XML API 41.11.0 Updates

Click here to download the XML API 41.11.0 schema.

XML API support forward compatibility in user management API for Control Hub managed sites

Impacted APIs and Schema changes

If your integration application is currently using Webex XMLAPI user management APIs: CreateUser, SetUser, DelUser, and GetUser to provision or manage users, after your Webex classic site converted into Control Hub managed site, these APIs will continue to work for forward compatibility. There are some behavior changes as noted below:

• When using createUser- if the user status in Control Hub isn’t "active" then the user's status on the site won’t be active. If the user status in Control Hub is active, then the user's status on the site is also active, reference: User status of new and converted users in Control Hub.

• The password element of CreateUser and SetUser APIs will be ignored, we start sending activation email to new users, users can click the link in the email to active new account and input new password.

• The active element of CreateUser API will be ignored, new user (not be verified) can't be activated through this parameter using API SetUser.

• The value of webExId element in the bodyContent of CreateUser APIs must be same as email. If webExId is different from email, we’ll treat the webExId same as email when storing it into WebDB and the value will be ignored.

• The value of webExId element in the bodyContent of SetUser APIs must be user identity of email address, you can change it using <email> in bodyContent.

• The SetUser API will support changing existing user's email: it’s successful if the operation account in SecurityContext is Control Hub full site administrator. Otherwise, the API reports error with new error code and message below:

  • 030120 The account must be a full site administrator to change email.

• The element newWebExId in the bodyContent of SetUser API will be ignored.

• The SetUser API tries to change to an email that is already in use, the API raises below new error code and error message:

  • 030118 Email is already used in Control Hub managed sites.

• The DelUser API deactivates the user at Webex meeting side and the corresponding meeting license is removed from the Webex site. This deactivated user can be reactivated by using API: SetUser (<active>ACTIVATED</active>) as long as the user is verified before.

• The CreateUser and SetUser APIs raises new error code and error message as shown below:

  • 030117, This user exists outside your org, so needs to be claimed, to move into your org through the claim user process. For steps on claiming the user into your org, see Claim Users to Your Organization (Convert Users). You’ll need to verify the domain that the user belongs to prior to claiming the user.

  • 030119 The CI access token must include scope webexsquare: admin when provisioning user.

Schema changes

No schema changes on those APIs: CreateUser, SetUser, DelUser, and GetUser.

API request and response example

CreateUser API request & response

API request:
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:serv="http://www.webex.com/schemas/2002/06/service"
xsi:schemaLocation="http://www.webex.com/schemas/2002/06/service http://www.webex.com/schemas/2002/06/service/service.xsd">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{site Admin account}</webExID>
<email>{site Admin account}</email>
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken>
or <accessToken>, when using CI "accessToken", it must include scope webexsquare:admin when provisioning user
</securityContext>
</header>



<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.CreateUser">
<webExId>Jack@qa.webex.com</webExId> --- it should is user identity of email address
<email>Jack@qa.webex.com</email>
<firstName>Jack</firstName>
<lastName>Smith</lastName>
<password>....</password>
<privilege>
<host>true</host>
</privilege>
<active>ACTIVATED</active> ---this parameter can't active the user directly until the user self activate itself via activation email.
</bodyContent>
</body>
</serv:message>

API response example:
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:use="http://www.webex.com/schemas/2002/06/service/user">
<serv:header>
<serv:response>
<serv:result>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="use:createUserResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<use:userId>23778617</use:userId>
</serv:bodyContent>
</serv:body>
</serv:message>

Affect APIs:

• CreateUser

• SetUser

• DelUser

XML API supports existing user's authentication forward compatibility after Webex classic site is converted to Control Hub managed site

Impacted APIs

After Webex classic site is converted into to Control Hub managed site, the value of <webExID> element in <securityContext> needs to be same as email, details below:

• For existing users created in Webex classic site, we support both old webExID (For example: Jack) and new webExID (the content is same as email, example: Jack@xx.com) to login, this authentication backward compatibility is for all XML APIs.

• For new users created in Control Hub managed sites, the value of webExID element must be same as email for login.

<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com; new user must use jack@xx.com
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken> or <accessToken>
</securityContext>
</header>

Affect APIs:

All XML APIs.

After Webex classic site converted into a Control Hub managed site, the value of <webExID> element <bodyContent> needs to be same as email, details below:

• For existing users created in Webex classic site, we support both old webExId(e.g.: Jack) and new webExId (the content is same as email, for example: Jack@xx.com) in bodyContent.

• For new users created in Control Hub managed sites, the value of webExId element has to be same as email in bodyContent.

<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com; new user must use jack@xx.com
</bodyContent>

Affect APIs: GetUser, SetUser, and DelUser.

Schema changes

No schema changes on any APIs.

API request and response example

GetUser API request & response

API request:
<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:serv="http://www.webex.com/schemas/2002/06/service"
xsi:schemaLocation="http://www.webex.com/schemas/2002/06/service http://www.webex.com/schemas/2002/06/service/service.xsd">
<header>
<securityContext>
<siteName>{siteName}</siteName>
<webExID>{userName}</webExID> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com; new user must use jack@xx.com
<sessionTicket>xxxx</sessionTicket> or <password> or <webExAccessToken> or <accessToken>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.GetUser or SetUser or DelUser">
<webExId>xxxx</webExId> --- existing users were created in webEx classic site, it can be: jack or jack@xx.com; new user must use jack@xx.com
</bodyContent>
</body>
</serv:message>

API response example:
...same as before

Enhancement recording view history report API to support in Webex Meetings, Webex Events (New), and Webex Events (Classic)

Impacted APIs

Current API: lstrecordaccessHistory and lstrecordaccessDetailHistory only support Webex Trainings recording view accessed history report. The new enhancement supports Webex Meetings, Webex Events (new), and Webex Events (classic) recording view accessed history report as well.

Schema changes

We support below new schema into API lstrecordaccessHistory in API request body:

<serviceTypes>
<serviceType>MeetingCenter</serviceType>
<serviceType>TrainingCenter</serviceType>
<serviceType>EventCenter</serviceType>
</serviceTypes>

Details

The API: lstrecordaccessHistory is able to return recording view accessed history for Webex Meetings, Webex Events (new), Webex Events (classic), and Webex Trainings.

• If there’s no serviceType specified in API request, the API of lstrecordaccessHistory returns Webex Trainings recording view accessed history only.

• When the serviceType is MeetingCenter, the API of lstrecordaccessHistory returns both Webex Meetings and Webex Events (new) recording view accessed history.

• When the serviceType is EventCenter, the API of lstrecordaccessHistory returns Webex Events (classic) recording view accessed history.

The API: lstrecordaccessDetailHistory is able to return details by recordID of Webex Meetings, Webex Events (new), Webex Events (classic), and Webex Trainings.

API request and response example

lstrecordaccessHistory API's request and response

<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<header>
<securityContext>
<webExID>{userName}</webExID>
<password>{password}</password>
<siteName>{siteName}</siteName>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.history.LstrecordaccessHistory">
<viewTimeScope>
<viewTimeStart>9/20/2021 00:00:00</viewTimeStart>
<viewTimeEnd>9/28/2021 23:59:59</viewTimeEnd>
</viewTimeScope>
<listControl>
<startFrom>1</startFrom>
<maximumNum>100</maximumNum>
</listControl>
<order>
<orderBy>RECORDID</orderBy>
<orderAD>ASC</orderAD>
</order>
<serviceTypes>
<serviceType>MeetingCenter</serviceType>
<serviceType>TrainingCenter</serviceType>
<serviceType>EventCenter</serviceType>
</serviceTypes>
</bodyContent>
</body>
</serv:message>

<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:history="http://www.webex.com/schemas/2002/06/service/history">
<serv:header>
<serv:response>
<serv:result>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="history:lstrecordaccessHistoryResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test TC-20210924 1324-1</history:recordName>
<history:creationTime>09/24/2021 13:28:13</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>2</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>TestErollment_001-20210610 1905-1</history:recordName>
<history:creationTime>06/10/2021 19:10:15</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:viewed>3</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>Test instant playback 2-20210705 0709-1</history:recordName>
<history:creationTime>07/05/2021 07:15:06</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>EC2.0_232423-20210922 0447-1</history:recordName>
<history:creationTime>09/22/2021 04:53:05</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>0</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test EC2.0-20210924 1315-1</history:recordName>
<history:creationTime>09/24/2021 13:19:00</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test MC-20210924 1319-1</history:recordName>
<history:creationTime>09/24/2021 13:25:12</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:recordAccessHistory>
<history:recordID>1XXXXXXX7</history:recordID>
<history:recordName>LstrecordaccessHistory test EC classic-20210924 1331-1</history:recordName>
<history:creationTime>09/24/2021 13:37:28</history:creationTime>
<history:registered>0</history:registered>
<history:downloaded>1</history:downloaded>
<history:viewed>1</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordAccessHistory>
<history:matchingRecords>
<serv:total>8</serv:total>
<serv:returned>7</serv:returned>
<serv:startFrom>1</serv:startFrom>
</history:matchingRecords>
</serv:bodyContent>
</serv:body>
</serv:message>

lstrecordaccessDetailHistory API's request and response

<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:serv="http://www.webex.com/schemas/2002/06/service">
<header>
<securityContext>
<webExID>{userName}</webExID>
<password>{password}</password>
<siteName>{siteName}</siteName>
</securityContext>
</header>
<body>
<bodyContent xsi:type=
"java:com.webex.service.binding.history.LstrecordaccessDetailHistory">
<recondID>1XXXXXX7</recondID>
<timeZoneID>20</timeZoneID>
</bodyContent>
</body>
</serv:message>

<?xml version="1.0" encoding="UTF-8"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:history="http://www.webex.com/schemas/2002/06/service/history">
<serv:header>
<serv:response>
<serv:result>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="history:lstrecordaccessDetailHistoryResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<history:recordDetail>
<history:viewID>1XXXXXX7</history:viewID>
<history:participantName>Axxxg</history:participantName>
<history:participantEmail>Axxxg@qa.webex.com</history:participantEmail>
<history:accessTime>09/24/2021 13:27:26</history:accessTime>
<history:registered>false</history:registered>
<history:downloaded>false</history:downloaded>
<history:viewed>true</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordDetail>
<history:recordDetail>
<history:viewID>1XXXXXX7</history:viewID>
<history:participantName>Axxxg</history:participantName>
<history:participantEmail>Axxxg@qa.webex.com</history:participantEmail>
<history:accessTime>09/24/2021 13:27:39</history:accessTime>
<history:registered>false</history:registered>
<history:downloaded>true</history:downloaded>
<history:viewed>false</history:viewed>
<history:timeZoneID>20</history:timeZoneID>
</history:recordDetail>
<history:matchingRecords>
<serv:total>2</serv:total>
<serv:returned>2</serv:returned>
<serv:startFrom>1</serv:startFrom>
</history:matchingRecords>
</serv:bodyContent>
</serv:body>
</serv:message>

Affect APIs:

• lstrecordaccessHistory

• lstrecordaccessDetailHistory

Fix the gap of max allowed Webex Events (Classic) description length between XMLAPI and Webex Page.

Impacted APIs

The XML API: CreateEvent and SetEvent's element of description will allow max 10000 characters inputs, if over size inputing, it will result in the new error code and message:

060068 Illegal input description. This description can't exceed 10000 characters.

Schema changes

No schema change.

API request and response example

CreateEvent API request and response

#API request example:
...
<body>
<bodyContent xsi:type="java:com.webex.service.binding.event.CreateEvent"
xmlns:att="http://www.webex.com/schemas/2002/06/service/event" xsi:schemaLocation="http://www.webex.com/schemas/2002/06/service/event http://www.webex.com/schemas/2002/06/service/event/event.xsd">
<accessControl>
<sessionPassword>111111</sessionPassword>
<listing>PRIVATE</listing>
</accessControl>
<metaData>
<sessionName>EC test</sessionName>
<description>.......Suppose you filling in 10000 characters in description.......</description>
</metaData>
...


------------------------------------
#API response example when the description exceeds 10000 characters:

<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>FAILURE</serv:result>
<serv:reason>Illegal input description. The description can't exceed 10000 characters</serv:reason>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
<serv:exceptionID>060068</serv:exceptionID>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent/>
</serv:body>
</serv:message>

Affect APIs:

• CreateEvent

• SetEvent

XML API: GetUser returns new element of freeAccount

Impacted APIs

GetUser returns a new element which identifiesfreeAccount the user account is FreeAccount or not.

Schema changes

GetUser response example

GetUser response:
<use:initials>AW</use:initials>
<use:isUploaded>false</use:isUploaded>
</use:avatar>
<use:largeEventCapacity>3</use:largeEventCapacity>
<use:freeAccount>false</use:freeAccount>
</serv:bodyContent>
</serv:body>
</serv:message>

Affect APIs:

GetUser

XML API 41.9.0 Updates

Click here to download the XML API 41.9.0 schema.

Decommission XML API 10.0.0 for all T31 sites

Webex plans to end of life support XML API ver 10.0.0 for all T31 sites.

We're decommissioning XML API 10.0.0 code from all productions in the 41.9.0 update.

XML API 41.8.0 Updates

Click here to download the XML API 41.8.0 schema.

Decommission XML API 10.0.0 for all T31 sites

Webex plans to end of life support XML API ver 10.0.0 for all T31 sites.

Webex found some customers client accessing XML API's URL using incorrect way as: https://{siteName}.webex.com/WBXService/xml10.0.0/XMLService, the right way accessing XML API URL as: https://{siteName}.webex.com/WBXService/XMLService.

Please switch your code access XML API using right way to avoid impact before we end of life support on XML API version 10.0.0.

XML API 41.7.0 Updates

Click here to download the XML API 41.7.0 schema.

Mobile delete and edit recording should be controlled by site administration option: Allow hosts to reassign, edit, disable, and delete recordings

Impacted APIs and Schema changes

GetSite: will return new elements naming enableNBRMCModify, and separateNoRecordingEdit under tools.

Response example

GetSiteResponse:

GetSite

<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:ns1="http://www.webex.com/schemas/2002/06/service/site" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="ns1:getSiteResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
....
<ns1:tools>
...
<ns1:enableNBRMCModify>false</ns1:enableNBRMCModify>
<ns1:separateNoRecordingEdit>true</ns1:separateNoRecordingEdit>
...
</ns1:tools>
</serv:bodyContent>
</serv:body>
</serv:message>

XML API 41.6.3 Updates

Click here to download the XML API 41.6.3 schema.

GetSite Response new element of supportLargeEvent

Impacted APIs and Schema changes

GetSite: returns new elements naming supportLargeEvent under siteCommonOptions to let caller know whether the site is support Large Event (Webex Event (new)) or not.

Schema change

Response example

GetSiteResponse:

GetSite

<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:ns1="http://www.webex.com/schemas/2002/06/service/site" xmlns:event="http://www.webex.com/schemas/2002/06/service/event">
<serv:header>
<serv:response>
<serv:result>SUCCESS</serv:result>
<serv:gsbStatus>PRIMARY</serv:gsbStatus>
</serv:response>
</serv:header>
<serv:body>
<serv:bodyContent xsi:type="ns1:getSiteResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
....
<ns1:siteCommonOptions>
...
<ns1:enablePreMeetingLobby>false</ns1:enablePreMeetingLobby>
<ns1:supportLargeEvent>true</ns1:supportLargeEvent>
</ns1:siteCommonOptions>
</serv:bodyContent>
</serv:body>
</serv:message>

XML API 41.6.0 Updates

Click here to download the XML API 41.6.0 schema.

XMLAPI support Webex Events 2.0 in provisioning

Impacted APIs

GetUser: returns new element naming largeEventCapacity which shows the capacity of new Event 2.0 (EC 2.0) under this user account. For example, if the user account has CI_EC3K license, the value of largeEventCapacity is 3000.

Schema changes

Response example

GetUserResponse:

XMLAPI LstRecording's CreateTime applies recording start time

Impacted APIs

LstRecording: LstRecording response CreateTime as the time when the user actually presses the record button.

Details

In the past, XML API used time stamp of when the recording was created in database as the create time in LstRecording response. Now it is the time the user actually starts to make the recording. This change applies to all service recordings. There is no schema change.

XML API 41.5.0 Updates

Click here to download the XML API 41.5.0 schema.

XMLAPI has ability to start Webex scheduled meetings from PSTN as host

Impacted APIs

• CreateUser: generates hostPIN regardless user PMR is enabled or not when the user role is host or full or read-only or user-management site administrators.

• SetUser: sets hostPIN using phones.hostPIN when personalMeetingRoom.hostPIN isn’t in XML request (pre-condition: feature toggle AllowStartScheduledMtgFromPhone is enabled).

• GetUser: returns phones.hostPIN regardless user PMR is enabled or not. (pre-condition: feature toggle AllowStartScheduledMtgFromPhone is enabled).

Schema Changes

GetUserResponse:

SetUser:

Response example

GetUserResponse:

SetUser:

XMLAPI GetSite response two new elements for mobile client

Impacted APIs

• GetSite: GetSite will now response two new elements to support mobile client has the logic to display or not display the recording tab.

  • enableRecordingAccess: true or false, Webex super administrators can enable or disable recording access by the toggle(EnableRecordingAccesses).

  • storageEmptyStatus: true or false, if both the sites don't support NBR function and allocated the NBR storage space as zero, then the status response is true, else is false.

Schema Changes

Sample Request for GetSite

Sample Response for Getsite

Email subject that has non-ASCII characters will be encoded with RFC2047. In case of a pure ASCII character email subject, there’s no encoding

There are no impacts on any API request, responses payload, but it changes email subject's encode behavior. When email's subject that has non-ASCII characters will be encoded with RFC2047. In case of a pure ASCII character email subject, there’s no encoding.

Schema Changes

There are no schema changes.

XML API 41.4.0 Updates

Click here to download the XML API 41.4.0 schema.

Create Event scheduled Webex Events can leverage site-level default on entry and exit tone

XMLAPI aligns with the current new logic for controlling entry and exit tone. All tones for Webex Events was controlled by a different setting in site administration. In GetSite, XMLAPI returns an extra field entryExitToneEC to indicate the value. Originally, when the site administrator set a default to the tone, create Event won’t leverage this setting by applying XMLAPI default.

Impacted APIs

The XML API: GetSite returns one new element entryExitToneEC to indicate the value.

The XML API: CreateEvent, SetEvent, GetEvent back end business logic reads the value of entryExitToneEC.

Schema changes

XML API: GetSite response sample:

<ns1:defaults>
<ns1:emailReminders>true</ns1:emailReminders>
<ns1:entryExitTone>ANNOUNCENAME</ns1:entryExitTone>
<ns1:entryExitToneEC>NOTONE</ns1:entryExitToneEC>
<ns1:voip>true</ns1:voip>
<ns1:teleconference>
<ns1:telephonySupport>NONE</ns1:telephonySupport>
</ns1:teleconference>
<ns1:joinTeleconfNotPress1>true</ns1:joinTeleconfNotPress1>
<ns1:updateTSPAccount>false</ns1:updateTSPAccount>
</ns1:defaults>

Affect APIs:

• GetSite

• CreateEvent

• SetEvent

• GetEvent

XMLAPI just returns the large event (Webex Event 2.0) detail information

1. If the Webex Meeting is the large event or webcast, GetSessionInfo returns some detail information including meeting password, meeting numeric password, panelist password, and panelist numeric password (No schema be changed).

2. XMLAPI doesn’t support creating and editing any large event or webcast feature, so CreateMeeting and SetMeeting return a new exception (110064, The event and webcast session type aren’t supported.) for large event or webcast case.

Impact APIs

XML API 41.3.0 Updates

Click here to download the XML API 41.3.0 schema.

The XML API new changes support Webex Events 2.0 feature

Impacted APIs

Both the APIs: GetSessionInfo and GetMeeting return elements enableEvent and enableWebniar too.

Schema changes

GetSessionInfo returns elements enableEvent and enableWebniar for EC 2.0.

GetMeeting returns elements enableEvent and enableWebniar for EC 2.0.

Response Sample:

GetSessionInfo response:

<ep:accessControl>
<ep:listStatus>PUBLIC</ep:listStatus>
<ep:registration>false</ep:registration>
<ep:passwordReq>true</ep:passwordReq>
<ep:isEnforceAudioPassword>false</ep:isEnforceAudioPassword>
<ep:isEnforceAudioLogin>false</ep:isEnforceAudioLogin>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>
</ep:accessControl>

GetMeeting response:

<meet:supportPKI>false</meet:supportPKI>
<meet:HQvideo>true</meet:HQvideo>
<meet:HDvideo>true</meet:HDvideo>
<meet:viewVideoThumbs>true</meet:viewVideoThumbs>
<meet:enableEvent>false</meet:enableEvent>
<meet:enableWebniar>false</meet:enableWebniar>
<meet:enablePreMeetingLobby>true</meet:enablePreMeetingLobby>
</meet:enableOptions>

The XMLAPI new changes support Pre-Meeting lobby feature

Impacted APIs

The XML API: GetSite, LstSummarySession, GetSessionInfo, and GetMeeting will response the new element enablePreMeetingLobby for Pre-Meeting Lobby.

Schema changes

The XML API: GetSite returns element enablePreMeetingLobby for Pre-Meeting Lobby.

The XML API: LstSummarySession returns element enablePreMeetingLobby for Pre-Meeting Lobby.

The XML API: GetSessionInfo returns element enablePreMeetingLobby for Pre-Meeting Lobby.

The XML API: GetMeeting returns element enablePreMeetingLobby for Pre-Meeting Lobby.

Response Sample:

GetSite response:

<ns1:siteCommonOptions>
<ns1:SupportCustomDialRestriction>false</ns1:SupportCustomDialRestriction>
<ns1:SupportTelePresence>false</ns1:SupportTelePresence>
<ns1:SupportTelePresencePlus>false</ns1:SupportTelePresencePlus>
<ns1:EnableCloudTelepresence>true</ns1:EnableCloudTelepresence>
<ns1:EnableCMRForAllUsers>true</ns1:EnableCMRForAllUsers>
<ns1:enablePersonalMeetingRoom>true</ns1:enablePersonalMeetingRoom>
<ns1:SupportAlternateHost>true</ns1:SupportAlternateHost>
<ns1:SupportXMLAPIReturnScheduledPMR>false</ns1:SupportXMLAPIReturnScheduledPMR>
<ns1:SupportAnyoneHostMeetings>true</ns1:SupportAnyoneHostMeetings>
<ns1:enablePreMeetingLobby>true</ns1:enablePreMeetingLobby>
</ns1:siteCommonOptions>

LstSummarySession response:

<ep:isException>false</ep:isException>
<ep:isNextUpcomingInstance>true</ep:isNextUpcomingInstance>
<ep:seriesMeetingKey>0</ep:seriesMeetingKey>
<ep:isScheduledPMR>false</ep:isScheduledPMR>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>
</ep:session>

GetSessionInfo response:

<ep:accessControl>
<ep:listStatus>PUBLIC</ep:listStatus>
<ep:registration>false</ep:registration>
<ep:passwordReq>true</ep:passwordReq>
<ep:isEnforceAudioPassword>false</ep:isEnforceAudioPassword>
<ep:isEnforceAudioLogin>false</ep:isEnforceAudioLogin>
<ep:enableEvent>false</ep:enableEvent>
<ep:enableWebniar>false</ep:enableWebniar>
<ep:enablePreMeetingLobby>true</ep:enablePreMeetingLobby>
</ep:accessControl>

GetMeeting response:

<meet:supportPKI>false</meet:supportPKI>
<meet:HQvideo>true</meet:HQvideo>
<meet:HDvideo>true</meet:HDvideo>
<meet:viewVideoThumbs>true</meet:viewVideoThumbs>
<meet:enableEvent>false</meet:enableEvent>
<meet:enableWebniar>false</meet:enableWebniar>
<meet:enablePreMeetingLobby>true</meet:enablePreMeetingLobby>
</meet:enableOptions>

The XML API GetSite response Information behavior change disclose

Impacted APIs

The XML API: GetSite only response below elements for administrator account, which include roles: SiteAdmin, RO_SiteAdmin, and UserAdmin.

<ns1:activeUserCount>...</ns1:activeUserCount>
<ns1:EEActiveUserCount>...</ns1:EEActiveUserCount>
<ns1:activeCETHost>...</ns1:activeCETHost>
<ns1:auoActiveUserCount>...</ns1:auoActiveUserCount>
<ns1:MCActiveUserCount>...</ns1:MCActiveUserCount>
<ns1:ECActiveUserCount>...</ns1:ECActiveUserCount>
<ns1:TCActiveUserCount>...</ns1:TCActiveUserCount>
<ns1:SCActiveUserCount>...</ns1:SCActiveUserCount>

Behavior changed

Only allow Admin role have response license data of GetSite. Host or attendee won't get those license data in GetSite response.

Below are API: GetSite's response example for siteadmin or ready-only siteadmin or user-management admin:

XML API 41.2.0 Updates

Click here to download the XML API 41.2.0 schema.

XMLAPI should support "CMR Hybrid VOIP" if the site supports Webex telephony

Impacted APIs

• GetSite returns a new element IsWebexTelephony in the response.

• CreateUser and SetUser can update the cmrHybridVoip element if IsWebexTelephony is true along with other conditions. IsTSPUsingTelephonyAPI is no longer consequential.

Schema changes

XML API: GetSite response returns an additional element IsWebexTelephony

GetSite response include this new element:

<ns1:telephonyConfig>

<ns1:isWebexTelephony>true</ns1:isWebexTelephony>
<ns1:isTSPUsingTelephonyAPI>false</ns1:isTSPUsingTelephonyAPI>
<ns1:serviceName>Personal Conference No.</ns1:serviceName>
<ns1:participantAccessCodeLabel>Attendee access code</ns1:participantAccessCodeLabel>
<ns1:subscriberAccessCodeLabel>Host access code</ns1:subscriberAccessCodeLabel>
<ns1:attendeeIDLabel>Attendee ID</ns1:attendeeIDLabel>

.....

</ns1:telephonyConfig>

LstSummarySession supports EC2.0

XML APIs be impacted

LstSummarySession will return new two elements to support EC 2.0

Schema changes

XML API: LstSummarySession: Append the <enableEvent> and <enableWebniar> elements

Response of XML API: LstSummarySession

Response for EC 2.0

<ep:isNextUpcomingInstance>true</ep:isNextUpcomingInstance>

<ep:seriesMeetingKey>0</ep:seriesMeetingKey>
<ep:isScheduledPMR>false</ep:isScheduledPMR>
<ep:enableEvent>true</ep:enableEvent>
<ep:enableWebniar>true</ep:enableWebniar>
</ep:session>

XMLAPI supports to return site user Webex-voice-assistant option for MCT integration

Affected API

GetUser returns a new element webexAssistantEnabled (true or false) in the response.

Schema changes

getUserResponse:

Response example