Webex Meetings > Develop and Test > XML API > Release Notes

XML API 9.0 Release Notes

Overview

This release note describes the changes made with the release of Webex® XML API 9.0. Changes described in this release note are backward compatible with existing integrations.

Important: Please note that this release includes changes to some of the XML API 9.0 schema. For more information, see the updated schema definitions below or refer to the full set of schema definitions on the release notes announcements page.

API Compatibility For WBS30 and "Spark Meet with Webex" Offers

With WBS30, Cisco Webex introduces the Common architecture and Common user profiles for Spark Meet with Webex new orders. There is some impact to API backward compatibility for sites provisioned this way. For more information, see API Compatibility below.

API Compatibility For Existing Webex Sites and WBS30 Sites Not Provisioned With Spark Meet

Existing sites that upgrade to WBS30 will not be on the Common architecture until a later release. The availability of the Common architecture is currently only available to new sites.

New WBS30 sites that are provisioned with offers other than "Spark Meet with Webex" will not be on the Common architecture until a later release.

Note: Only non-lockdown sites will be upgraded to WBS30. 


API Compatibility: WBS30 sites for Spark Meet with Webex

Description:

There are two ways that new integrations of WBS30 can be set up with the Webex service:

  • Spark Meet with Webex WBS30
  • Webex WBS30 without Spark Meet
In WBS30, Cisco Webex introduces features associated with a Common Identity site (CI-site): Common architecture and Common user profiles. These features are only available with new orders of Spark Meet with Webex. There is some impact to API backward compatibility for sites provisioned this way as explained in detail below. The most significant impact is the limit of CI-enabled sites to perform user provisioning through API calls. On a CI-enabled site, operations associated with user provisioning are not supported through the API.

Note: Existing sites that upgrade to WBS30 will not be on the Common architecture until a later release. Only Non-lockdown sites will be upgraded.

Note: On CI-enabled sites, the webExID of a user is the same as their email address. In the examples that follow, notice that requests to CI-enabled sites use an email address for the sample value of the webExID element .

API Compatibility and Authentication

The XML API that supports WBS30 maintains backward compatibility for the following authentication mechanisms:
  • username/password
  • Token obtained through SAML Response
  • One Time Login Ticket
The XML API that supports WBS30 does not support the following functionality or has limited functionality:
  • NOT supported: Partner SAML is not supported through the XML API.
  • NOT supported: User provisioning and de-provisioning operations are not supported through the APIs (requests to create a new user (createUser), to delete a user (delUser), or to activate a user (activateUser) will not be successful).
  • LIMITED support: Modifying Webex-specific attributes through APIs continues to be supported, but updates (changes or modifications) to attributes that are part of the common user profile are not be supported. See setUser below for the list of attributes that cannot be modified.

Affected APIs

CreateUser, SetUser, DelUser, ActivateUser, AuthenticateUser
createUser
For non-CI-enabled sites, the createUser API works the same as in the previous release. There is no change to the createUser API for sites that are not CI sites.

For CI-enabled sites, a request sent to the createUser API will result in a response that contains the following exception message:

030098: User management is not allowed on unified site
Example Request to a CI site to createUser
<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xmlns:serv="http://www.webex.com/schemas/2002/06/service">
<header>
 <securityContext>
 <siteName>acme</siteName>
 <webExID>admincred@acme.com</webExID>
 <password>P@ssword123</password>
 <partnerID>mypartnerID</partnerID>
 </securityContext>
</header>

<body>
 <bodyContent xsi:type="java:com.webex.service.binding.user.CreateUser">
  <firstName>Jane</firstName>
 <lastName>Doe</lastName>
 <webExId>Jane.Doe@acme.com</webExId>
  ...
 </bodyContent>
</body>
</serv:message>
Example Response from a CI site to createUser
<?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:use="http://www.webex.com/schemas/2002/06/service/user">
<serv:header>
 <serv:response>
 <serv:result>FAILURE</serv:result>
 <serv:reason>User management is not allowed on unified site</serv:reason>
 <serv:gsbStatus>PRIMARY</serv:gsbStatus>
 <serv:exceptionID>030098</serv:exceptionID>
 </serv:response>
</serv:header>
<serv:body>
 <serv:bodyContent/>
</serv:body>
</serv:message>
setUser
Requests sent to the setUser API on a CI-enabled site ignores some fields that are defined in the API. Note that the schema has not been changed; but certain fields are ignored. The attributes/elements/fields that are ignored on a CI-enabled site are:

newWebexId, firstName, lastName, title, address, phones,
email, email2, password, passwordHint, passwordHintAnswer,
timeZone, timeZoneID, timeZoneWithDST,
locale, language, languageID, active, security

We recommend that your client applications not use the above elements in a setUser request sent to a CI-enabled site.
Example Request setUser API sent to CI site
<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:serv="http://www.webex.com/schemas/2002/06/service">
<header>
 <securityContext>
 <webExID>siteadmin@acme.com</webExID>
 <password>P@ssword1234</password>
 <siteID>5941234567</siteID>
 <partnerID>mywebexpartnerid</partnerID>
 </securityContext>
</header>
<body>
 <bodyContent xsi:type="java:com.webex.service.binding.user.SetUser">
 <webExId>JohnDoe@acme.com</webExId>
 <security>
 <forceChangePassword></forceChangePassword>
 </security>
 </bodyContent>
</body>
</serv:message>
Example Response from setUser API
<?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: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:setUserResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</serv:body>
</serv:message>
delUser
For non-CI-enabled sites, the delUser API works the same as in the previous release. There is no change to the delUser API for sites that are not CI sites.

For CI-enabled sites, a request sent to the delUser API will result in a response that contains the following exception message:

030098: User management is not allowed on unified site
activateUser
For non-CI-enabled sites, the activateUser API works the same as in the previous release. There is no change to the activateUser API for sites that are not CI sites.

For CI-enabled sites, a request sent to the activateUser API will result in a response that contains the following exception message:

030098: User management is not allowed on unified site
authenticateUser
For non-CI-enabled sites, the authenticateUser API works the same as in the previous release. There is no change to the authenticateUser API for sites that are not CI sites.

For CI-enabled sites, a request to the authenticateUser API can use an accessToken as the input credential. The authentication server validates the input credential, and if successfully authenticated, returns a value for the sessionTicket element, a createTime value, and a timeToLive value (in seconds).

Be aware of the new exception message associated with this kind of request:

200006 : AS Server response error

The authentication server can also return the exception: 

000035: ASService not responding
Example Request to a CI site to authenticateUser with accessToken
<?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>
 <siteName>acme</siteName>
 <webExID>Jane.Doe@acme.com</webExID>
 </securityContext>
</header>
<body>
 <bodyContent xsi:type="java:com.webex.service.binding.user.AuthenticateUser">
 <accessToken>YWM3MTBlN2QtMDNlZi00NThiLWJhYTItYTEwNzZhNzhmOWZjN2I5YTABQRYRRRRRRRz</accessToken>
 </bodyContent>
</body>
</serv:message>
Example Response from CI Site
<?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:authenticateUserResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <use:sessionTicket>AAABTVl7rcMAAUijMSZH...DdXvmqww/dbXhzNvdA6pjHPtynb9b7dF35zsn/l2hvA=</use:sessionTicket>
 <use:createTime>1431725387202</use:createTime>
 <use:timeToLive>5400</use:timeToLive>
 </serv:bodyContent>
</serv:body>
</serv:message>


Site Type Information

Description:

The release of WBS30 introduces a new API that allows you to identify a site's type: Unified, Standalone, Standalone SSO (single sign on). 

  • Unified sites are WBS30 sites created from Spark Meet with Webex Orders.
  • Standalone and Standalone SSO sites are all other existing or new WBS30 sites.

New API: 

getSiteType
A request for getSiteType requires that the siteName be included in the header portion of the request. The server returns the site's type as a number as explained below.

The following diagram shows the getSiteType element that should passed in a request message:
getSiteType Request

The following diagram shows the getSiteTypeResponse element that the server returns with a successful response to the getSiteType request.
getSiteType Response
The returned element siteType is a long datatype. The following are the possible valid values:
  • 1 = CI
  • 2 = SSO
  • 3 = Train Non-SSO
  • 4 = W11 SSO
  • 5 = Non-SSO

Obtaining information about the site type can be useful in identifying and supporting mobile login scenarios.


Example Request

The following sample shows an example of a request for site type information. In this example, the request is for a  siteName called acme.



<?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>
            <siteName>acme</siteName>
        </securityContext>
    </header>
<body>
    <bodyContent xsi:type="java:com.webex.service.binding.ep.GetSiteType">
    </bodyContent>
</body>
</serv:message>

Example Response

<serv:message
    xmlns:serv="http://www.webex.com/schemas/2002/06/service"
    xmlns:com="http://www.webex.com/schemas/2002/06/common"
    xmlns:ep="http://www.webex.com/schemas/2002/06/service/ep"
    xmlns:meet="http://www.webex.com/schemas/2002/06/service/meeting">
<serv:header>
  <serv:response>
  <serv:result>SUCCESS</serv:result>
  <serv:gsbstatus>PRIMARY</serv:gsbstatus>
  </serv:response>
</serv:header>
<serv:body>
  <serv:bodycontent xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ep:getSiteTypeResponse">
    <ep:sitetype>3</ep:sitetype><br>
  </serv:bodycontent>
</serv:body>
</serv:message>

Personal Room Enhancements

Description:

This release includes enhancements to Personal Rooms, providing more controls to users. These enhancements have been made in the XML API:
  • User can set auto-lock preference
  • User can set auto-lock wait time preference
  • User can set Personal Room notifications preferences
  • If Webex site is set up for “PR Force Login”, GetSessionInfo API returns the flag

Two new data types have been added to user.xsd: PRNotificationTypeEnum and PRNotificationType. Three new attributes have been added to the PersonalMeetingRoomType element: PMRAutoLock, PMRAutoLockWaitTime, and PRNotifications.

Affected APIs

createUser, setUser, getSessionInfo

createUser
There are 3 new attributes available in the personalMeetingRoomType element. These attributes can be used with a call to the createUser API.  Any, all or none of these attributes can be part of a createUser request. If a value is not specified in the createUser request, a call to GetUser returns default values for these attributes.

Example Request
The following XML snippet shows an example of a portion of a request for createUser using the new attributes: PMRAutoLock, PMRAutoLockWaitTime, and PRNotifications.

<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.CreateUser">
 ...    

    <personalMeetingRoom>
       <PMRAutoLock>false</PMRAutoLock>
       <PMRAutoLockaitTime>17</PMRAutoLockWaitTime>
       <PRNotifications>
         <mode>EMAIL</mode>
         <mode>SMS</mode>
       </PRNotifications>
    </personalMeetingRoom>
 ...

</bodyContent>
</body>

On a CI-enabled site, a call to the createUser API will return the following new exception message:



030098: User management is not allowed on unified site

Example Response On a CI-Enabled Site
<?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:use="http://www.webex.com/schemas/2002/06/service/user">
<serv:header>
  <serv:response>
    <serv:result>FAILURE</serv:result>
    <serv:reason>User management is not allowed on unified site</serv:reason>
    <serv:gsbStatus>PRIMARY</serv:gsbStatus>
    <serv:exceptionID>030098</serv:exceptionID>
  </serv:response>
</serv:header>
<serv:body>
  <serv:bodyContent/>
</serv:body>
</serv:message>

setUser

There are 3 new attributes available in the personalMeetingRoomType element:

  • PMRAutoLock,
  • PMRAutoLockWaitTime, and
  • PRNotifications.

These attributes can be used with a call to the setUser API.  Any, all or none of these attributes can be part of a setUser request. If a value is not specified in the setUser request, a call to GetUser returns default values for these attributes.

getSessionInfo
The getSessionInfo API for PMR meetings includes a field in the returned Response: <ep:joinRequiresAccount>. This field is returned based on the site level flag PMR_ForceLogin. A value of "1" indicates true, other values or a value of null indicates false. A non-PMR meeting uses the flag at the meeting level.

The following figure shows the PMR flag in the site admin console:

PMR ForceLogin

Collaboration Meeting Room (CMR) Enhancements

Description:

A GetSessionInfo request returns an SIP URL if the meeting is CMR enabled.

Affected APIs

getSessionInfo

getSessionInfo
The request message for getSessionInfo has not changed. However there is a new element defined for the Response that provides information about the SIP URL for a CET-enabled meeting.

The following diagram shows a portion of the getSessionInfoResponse element and its new child element: sipURL.
getSessionInfoResponse element

Example Request

The following sample shows an example of a getSessionInfo request message. The schema of this request message has not changed in this release.



<?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>
    <webExID>ysmith</webExID>
    <password>*****</password>
    <siteName>xmlt30</siteName>
  </securityContext>   
</header>
<body>
  <bodyContent xsi:type="java:com.webex.service.binding.ep.GetSessionInfo">
    <sessionKey>987654321</sessionKey>
  </bodyContent>   
</body>
</serv:message>

Example Response
The following sample shows an example of a getSessionInfoResponse message. Notice that bodycontent of this Response contains the <ep:sipURL> element.

<?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:ep="http://www.webex.com/schemas/2002/06/service/ep"
    xmlns:meet="http://www.webex.com/schemas/2002/06/service/meeting">
  <serv:header>
      <serv:response>
          <serv:result>SUCCESS</serv:result>
          <serv:gsbStatus>PRIMARY</serv:gsbStatus>
      </serv:response>
  </serv:header>
  <serv:body>
      <serv:bodyContent
         xsi:type="ep:getSessionInfoResponse"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <ep:status>NOT_INPROGRESS</ep:status>
          <ep:sessionkey>987654321</ep:sessionkey>
          <ep:confID>2516583027</ep:confID>
          <ep:accessControl>
              <ep:sessionPassword/>
              <ep:listStatus>UNLISTED</ep:listStatus>
              <ep:registration>false</ep:registration>
              <ep:passwordReq>false</ep:passwordReq>
          </ep:accessControl>
          <ep:metaData>
              <ep:confName>Craig Lin's Personal Room</ep:confName>
              <ep:sessionType>3</ep:sessionType>
              <ep:serviceType>MeetingCenter</ep:serviceType>
              <ep:isRecurring>false</ep:isRecurring>
              <ep:agendaFormat>TEXT</ep:agendaFormat>
              <ep:descriptionFormat>TEXT</ep:descriptionFormat>
              <ep:isException>false</ep:isException>
              <ep:seriesMeetingKey>0</ep:seriesMeetingKey>
              <ep:hasException>false</ep:hasException>
          </ep:metaData>
          <ep:telephony>
              <ep:telephonySupport>CALLBACK</ep:telephonySupport>
              <ep:tollFreeRestrictionsURL>https://www.webex.com/pdf/tollfree_restrictions.pdf</ep:tollFreeRestrictionsURL>
              <ep:callInNum>
                  <serv:tollNum>4083822469</serv:tollNum>
                  <serv:tollFreeNum>4083822470</serv:tollFreeNum>
              </ep:callInNum>
              <ep:labels>
                  <ep:tollFreeCallInLabel>Call-in toll-free number (US/Canada)</ep:tollFreeCallInLabel>
                  <ep:tollCallInLabel>Call-in toll number (US/Canada)</ep:tollCallInLabel>
              </ep:labels>
              <ep:isMPAudio>false</ep:isMPAudio>
              <ep:voip>true</ep:voip>
              <ep:enableTSP>false</ep:enableTSP>
          </ep:telephony>
          <ep:host>
              <ep:firstName>Craig</ep:firstName>
              <ep:lastName>Lin</ep:lastName>
              <ep:email>yangseli@cisco.com</ep:email>
              <ep:webExId>yangseli</ep:webExId>
          </ep:host>
          <ep:schedule>
              <ep:startDate>12/31/2065 13:00:00</ep:startDate>
              <ep:duration>720</ep:duration>
              <ep:timeZone>GMT-08:00, Pacific (San Francisco)</ep:timeZone>
              <ep:timeZoneID>4</ep:timeZoneID>
          </ep:schedule>
          <ep:attendeeOptions>
              <ep:joinRequiresAccount>false</ep:joinRequiresAccount>
          </ep:attendeeOptions>
          <ep:isAudioOnly>false</ep:isAudioOnly>
          <ep:telePresence>false</ep:telePresence>
          <ep:isAlternateHost>false</ep:isAlternateHost>
          <ep:isCreator>true</ep:isCreator>
            <ep:supportE2E>false</ep:supportE2E>
          <ep:isAllowJBH>false</ep:isAllowJBH>
          <ep:isCETMeeting>true</ep:isCETMeeting>
          <ep:isPersonalMeetingRoom>true</ep:isPersonalMeetingRoom>
          <ep:isNextUpcomingInstance>true</ep:isNextUpcomingInstance>
          <ep:sipURL>xyz123@xmlt00.eng.webex.com</ep:sipURL>
      </serv:bodyContent>
  </serv:body></serv:message>

Security Enhancements

Description:

If a site is enabled via site admin flag to create passwords for audio login, scheduling a meeting through pages will set password automatically and getSessionInfo will return the audio Password. Once a site is enabled for this feature, integrations should be updated to provide this password to users who are joining the meetings with the audio only option.

Affected APIs

getSessionInfo

getSessionInfo
The request message for getSessionInfo has not changed. However this release introduces three new return elements in the GetSessionInfoResponse message. These new elements are children of the ep:accessControl element:
  • ep:audioPassword
  • ep:isEnforceAudioPassword
  • ep:isEnforceAudioLogin

When both superadmin and siteadmin enabled audio password feature, schedule meeting will automatic generate the audio password if session password is provided. The privilege to return the audio password is as same as session password.



Example Request
The following sample shows an example of a getSessionInfo request message. The schema of this request has not changed in this release.

<?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>
    <siteName>acme</siteName>
    <webExID>jsmith</webExID>
    <password>Aaa123456</password>
    <partnerID>s-8fiij-...PMok_wVvH0YW6by71Chg</partnerID>
  </securityContext>
</header>
<body>
  <bodyContent xsi:type="java:com.webex.service.binding.ep.GetSessionInfo">
    <sessionKey>21000742</sessionKey>
  </bodyContent>
</body>
</serv:message>

Example Response

The following XML snippet shows an example of a getSessionInfoResponse message. Notice the security-related elements in the Response contained by the <ep:accessControl> element:


  • <ep:audioPassword>
  • <ep:isEnforceAudioPassword>
  • <ep:isEnforceAudioLogin>

<?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:ep="http://www.webex.com/schemas/2002/06/service/ep"
  xmlns:meet="http://www.webex.com/schemas/2002/06/service/meeting">
<serv:header>
  <serv:response>
    <serv:result>SUCCESS</serv:result>
    <serv:gsbStatus>PRIMARY</serv:gsbStatus>
  </serv:response>
</serv:header>
<serv:body>
  <serv:bodyContent
    xsi:type="ep:getSessionInfoResponse"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <ep:status>NOT_INPROGRESS</ep:status>
    <ep:sessionkey>210007422</ep:sessionkey>
    <ep:confID>1038708515</ep:confID>
    <ep:accessControl>
      <ep:sessionPassword>F46SbDh2</ep:sessionPassword>
      <ep:listStatus>PUBLIC</ep:listStatus>
      <ep:registration>false</ep:registration>
      <ep:passwordReq>true</ep:passwordReq>
      <ep:audioPassword>40008424</ep:audioPassword>
      <ep:isEnforceAudioPassword>true</ep:isEnforceAudioPassword>
      <ep:isEnforceAudioLogin>true</ep:isEnforceAudioLogin>
    </ep:accessControl>
    <ep:metaData>
    <ep:confName>testAudio</ep:confName>
    <ep:sessionType>3</ep:sessionType>
    <ep:serviceType>MeetingCenter</ep:serviceType>
    <ep:isRecurring>false</ep:isRecurring>
...

</serv:body>
</serv:message>

Enhancement To User Authentication

Description

In order to better support user authentication, WBS30 adds support for passwords as well as support for Common Identity (CI) access tokens.

In releases before WBS30, the authenticateUser API did not validate user passwords. Previous releases were able to validate SAML assertions from an Single-Sign-on (SSO) site. In WBS30, authentication has been expanded to accept passwords on SSO sites (in addition to SAML assertions) and passwords or CI Oauth access tokens on CI sites as methods of user authentication.

In order to support backward compatibility, we follow a specific order of priority checks of the input credentials as follows.

SSO Sites

Order of processing input credentials for SSO sites:

  1. samlResponse
  2. password
The authentication server validates the input credentials, and if successfully authenticated, returns a value for the sessionTicket element.
CI Sites
Order of processing input credentials for CI sites:
  1. password
  2. accessToken
The authentication server validates the input credentials, and if successfully authenticated, returns a value for the sessionTicket element, a createTime value, and a timeToLive value (in seconds).

Affected APIs

authenticateUser
authenticateUser
The schema of authenticateUser now allows for the passing of a user password.

NOTE: For a CI-enabled site, the user name is the same as the user's email address.

Example Request (using a password on a CI-enabled site)
<?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>
 <siteName>acme</siteName>
 <webExID>username.on.ciintegration@acme.com</webExID>
 <password>P@ssword000</password>
 <partnerID>s-PMok_wVv_EG_Mock</partnerID>
 </securityContext>
</header>
<body>
 <bodyContent xsi:type="java:com.webex.service.binding.user.AuthenticateUser">
 </bodyContent>
</body>
</serv:message>

Example Response (from a CI-enabled site)
<?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:authenticateUserResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <use:sessionTicket>AAUQEAABUYA0g4d9y3+7Ec+u7r7hCHb/6KahNeWMcQu+A0WGLGavQeTAAEADJ5vZ3QPBAjLqqVgYr/h54r9KGsYiVVeiBahzQL/RFSsKGN/s701lMsIVtOwQrWMi7b2BY1fZOpfu8mlCTw4PYRDiZzz3aCqM7iAjk57lERlyboEQ4Zs1HBO4EnX+v2lW9XcKFHhlRWyCKtNnghpiGEtt1m3RpbXGd67ehlyjLSO/9eSbs7buN1SRttEauWAoTTrJzdswvRAoF4zHhtWCBmrNQmBiXlEpNCuwJlYV2LxkUudo5H6O15vv0KnzWxiKRoKD0tofg02hfJr/tV5Vq0
 </use:sessionTicket>
 <use:createTime>1427846353152</use:createTime>
 <use:timeToLive>5400</use:timeToLive>
 </serv:bodyContent>
</serv:body>
</serv:message>

Related Release Information

The XML API schemas and release notes are available at the Cisco Webex Developer Portal:

https://developer.cisco.com/site/collaboration/webex/webex-developer/develop-test/xml-api/reference/

The URL API release notes are available at the Cisco Webex Developer Portal:

https://developer.cisco.com/site/collaboration/webex/webex-developer/develop-test/url-api/reference/

These release notes last updated: 04-AUG-2015