Salesforce OpenCTI API provides now a feature to add standby URL, so that after a set timeout, if the primary CTI page does not send initialization complete, the Salesforce will load the page configured in reqStandbyUrl (Standby CTI URL).

With this feature, when the primary CTI URL page is loaded, we can access all the OpenCTI functions. But if the same page is loaded as a standby URL, the opencti functions done return any response or callback is never called.

This seems to happen with just the sample page OpenCTI developer's guide provides.

No error appears in the JS console...

Can somebody help?


In my opinion, this is clearly a bug within the salesforce OpenCti API release 29 and salesforce has to address this. I've logged a case in the salesforce.com partner portal concerning this behavior.

Some additional information, about why the OpenCti requests from the secondary URL, are silently failing:

API requests are working correct, as long as they are executed from the primary URL. But as soon as salesforce switches over to the Standby URL in case of an outage of the primary server, the interaction.js of the OpenCti API silently discards all requests. In case the requests are sent form the Standby URL, they are rejected within the InteractionFramework.js (please refer to the attached screenshot) because of an origin check still testing the post message origin against the primary Server. This check is failing because you've been redirected to the standby URL in the meantime.

enter image description here (source, please adapt the URL to your sfdc org: /jslibrary/1383366200000/sfdc/InteractionFramework.js)

enter image description here

  • Is this an update to the question ? Ifso, editing it in would make more sense than posting it as an answer Jan 23 '14 at 12:43
  • @Sdry: I tried to rephrase the answer. Hope this clarifies it.
    – it's me
    Jan 23 '14 at 13:24
  • I raised this issue through SFDC Partner portal also and the Salesforce Product management worked with me to identify the issue and accepted, it will be fixed in the Spring 14 release. Thanks to Gautam@Salesforce and team for a prompt response.
    – Siva
    Jan 30 '14 at 20:48
  • @Siva That's great news. Thank you for letting us know. Is there a "known issue id" or a "partner portal case number" that you could share with us?
    – it's me
    Jan 31 '14 at 10:26

Double check to ensure that you have set the reqTimeout parameter as well as the reqStandbyUrl parameter. If you are not receiving a response of the callback is not triggered, there's a strong possibility that the reqTimeout parameter is not set or has been set to an incorrect value.

If that's not the issue, can you post your call definition file and I'll be happy to take a look further.

  • reqtimeout is set and because of that, the standby URL is getting loaded properly for the set timeout. CC XML snippet.. <item sortOrder="6" name="reqStandbyUrl" label="CTI Standby Adapter URL">localhost:8080/indexStandbytest2.html</item> <item sortOrder="7" name="reqTimeout" label="TimeoutInMSecs">10000</item>
    – Siva
    Jan 14 '14 at 15:02

Updating this thread to indicate that this issue was resolved in Feb-March 2014 with the Spring '14 release by salesforce.

In case anyone runs into it looking for an update : )

  • 1
    Hi SFDCAnon! Welcome to salesforce.stackexchange. Could you provide a link or some other reference in the docs to what was fixed in the API that resolved this issue? Doing so would be most appreciated. As a new user, you haven't earned the points needed to comment on a post which would be appropriate with the level of detail that you've posted. Without providing some sort of reference or sharing more information, what you've related doesn't seem to suffice as an answer when you've not established yourself as a user by earning reputation.
    – crmprogdev
    Jul 17 '14 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.