API

Frequently Asked Questions

User Experience

Integration

Technical: Managing Share Sessions

Billing and Time

Features

Implementation

Troubleshooting

Privacy

Administration

User Experience

Can I integrate Screenleap into my web application so that my users don't realize they're using Screenleap?

Yes. The share session console will have your company name in the title bar - not Screenleap. They can launch the share session through controls in your site. You can also hide the controls on the viewer and embed it as an iframe within your own pages if you choose.

Will my users need to install anything on their machines?

With our installation-free sharing option, the user will not need to install anything on their computers in order to share their screen with you. IF you choose to integrate with our native apps, the user who is sharing his/her screen will need to install one of the desktop apps for Windows or Mac. The users who view the share session don't need anything other than a web browser! See the API Introduction for more details about Requirements.

Integration

When integrating with the native apps, how do I show the instructions with the link to manually start the share session using the custom protocol handler like in the API demo?

You need to implement the screenShareStartError callback and pass it to the screenleap.startSharing call. When you call screenleap.startSharing, we will attempt to automatically try to start the share session using the custom protocol handler 20 seconds after the presenter app is downloaded. The start attempt will fail however if the user has not installed the presenter app by then.

To allow users who miss the automatic attempt to start the share session, you need to provide your users with a manual way of opening the custom protocol handler permission window. You can do this by showing instructions with the link to manually start the custom protocol handler in the screenShareStartError callback. Please see the page source for the reference integration for an example.

How can I determine if a user has already installed the native presenter app?

Unfortunately, it is not possible to directly detect whether a user has the native presenter app installed. What we do is set a cookie "__aa" when a share session is successfully started. If we detect the presence of the cookie on a subsequent share session, we do not attempt the download and immediately try to start the screen share. If the cookie is not available, we start the download first.

If you need to detect whether the presenter app has been installed on your side, the best way to do it is to implement the screenleap.onScreenShareStart callback and set a cookie on the user's computer. You can then check for the presence of the cookie to determine if the user has successfully installed the app.

Technical: Managing Share Sessions

How can I close out users who leave their share sessions open for too long?

The best method is to make a server-side API call to stop the share session. You can also redirect the presenter to a new web page, but in some cases this will not properly trigger the JavaScript callback, so the server-side API call is preferred.

Can I have multiple concurrent share sessions running at the same time?

Yes, the API is designed for this. You can use the API to launch as multiple share sessions and have them all running at the same time.

Can I reuse a share code for a new share session?

Once a share session ends, you cannot use the share code again. This is because the share session duration is calculated from the time the presenter app first connects to the time the presenter ends the share session.

We do allow a share session to be reopened if it was stopped because the presenter app crashes or if the user closes his/her browser window. The latter case is because we cannot determine if the user intentionally ended the screen share or if the user is reloading the page to try to fix a connection problem. In both cases, we allow the share session to be reopened for five minutes after the share session ends.

How can I implement presenter swap using the API?

You can implement presenter swap using the API by stopping the existing share session, making a new API request to create a new share session, and then launching the share for the new presenter. You would repeat the process each time you want to switch the presenter.

Can I make a bunch of share codes in advance, and use them later?

No. When you make the share session, you will receive some HTML that launches the presenter app for sharing. This HTML is always updated to use the most recent release. So if you create the share sessions in advance and try to use them later, your HTML might be outdated.

If the purpose of making share codes in advance is to implement a scheduling feature and send links to users in advance, you can certainly send them links to your own domain, and then make the share session API call when the presenter actually clicks to start the share/meeting. You could also choose to implement a "waiting room" page on your site, to which you automatically push the viewerUrl when the share starts.

In PHP, I get a content length error when I try to start a share session.

PHP's curl POST expects there to be some post fields. So you have two options:

  1. Pass the account ID as a POSTFIELD instead of in the header. (The authtoken must always be passed in the header, but the accountid can be passed via either header or post fields.) See the Sample PHP Code on the Presenter Integration page for an example.
  2. Set the POST fields to null. (curl_setopt($ch, CURLOPT_POSTFIELDS, null);)

How can I get information about a share session ending?

If the app closes through normal means (like the user clicking the "stop" button), it will make a callback to JavaScript -- both to let the web page know that the share session ended, and to pass along some info about the share session in case you need to record it. See Step 3 of Presenter Integration for more information

You can also implement the callbackUrl to have our servers send the data to your servers when the share session ends. We will make an HTTP POST request with the data about the event. The data will have a content type of "application/json". Depending on how the share session ends, there may be a delay of several minutes. (For example, if the presenter loses their internet connection, we hold the share session open a few minutes to see if the connection comes back before closing it out.) See the API Reference for Making a new share session request for more information.

Billing and Time

How is the duration of the share session calculated?

The billable time of the share session begins when all of the following are true:

  • The app has opened and connected to our servers.
  • At least one viewer has connected.
  • The share session is not paused. (The presenter can pause/resume the share session via buttons in the console. See Make a new share session request in the API Reference for more information.)

The share session ends when the first of these cases is met:

  • The user clicks the Stop button.
  • The app receives an API call to stop the share session. See Stop an active share session in the API Reference for more information.
  • Our servers have not heard from the app in 5 minutes. This can happen when the app closes unexpectedly or loses its internet connection.

Does the price go up if there are more viewers?

Yes, the pricing is usage-based and increases with the number of participants in a share session. Please see the API pricing page for more information.

Can I try out the API without giving out my credit card?

Absolutely! You can make a free Screenleap Developer Account to get an API key, without entering any billing information. Your first 5 hours (at the $0.01/minute/participant rate) are free so you can try out the API risk-free.

How can I find out how many minutes of credit I have left?

If you click into the Developer page under the Account menu in the upper right corner of the site, you'll find a summary of your share sessions this month, as well as how many free credits remain.

I was testing out the API and accidentally left open a share session, so I ran out of free minutes. Is there any way for me to keep testing?

Yes, please contact us for support.

Features

Can I record a share session?

Yes, we support recording the screen during your API share session. Please see API recording for more information.

Implementation

Under what conditions will the integration attempt to start the share session using the local web server?

If you have configured your integration to start the native app using the custom protocol handler, we will actually first make an attempt to start the share session using the local web server. If it fails, then we attempt to start the share session using the custom protocol handler. We do this because it gives the user a better screen share experience to start the share session using the local web server if it's supported because it does not require asking the user for permission to use the custom protocol handler.

The attempt to start the share session using the local web server will succeed if:

  • The presenter app is running in the background.
  • The user is on a network not behind a proxy or behind a proxy that allows local network connections.

Troubleshooting

What do my users need to change in their proxy settings to allow the screen sharing integration to work correctly?

You should make sure that your users have all subdomains of screenleap.com unblocked (i.e., *.screenleap.com) as well as the standard HTTP and HTTPS ports (80 and 443).

Why do I get a BAD REQUEST when I make the POST for a new share session?

Verify that your initial request for a share session is secure. This protects your authtoken. Failure to use https will generate a BAD REQUEST.

If you continue to get a BAD REQUEST with a secure request, parse the JSON that is returned in the response body. The errorMessage element should provide more information about the specific error.

The number of viewers reported for some of my share sessions exceed the actual number of viewers. How do I fix this?

Safari 6 and above disables third-party cookies by default. Since we use cookies to track unique viewers, the total viewer count will be incorrect for viewers on Safari 6 if you embed the viewer in an iframe and one of your viewers reloads the viewer page. Each time a viewer reloads the viewer page, the total viewer count will increase by one (even though it's the same viewer).

The fix is to always add a unique external ID to the viewer URL for each viewer so that we can uniquely identify each viewer.

I see "https://0111001101101100.com:5327/status net::ERR_CONNECTION_REFUSED" in my browser console when starting a share session. How can I fix it?

This is a normal result of a check that we perform to see if the native app is running. The error simply means that the native app is not installed and running. It is an expected error that you can ignore.

If you get this error when you have the native app is running, then it is likely that you are behind a proxy and we cannot use local communication to communicate with the native app. In this situation, we will try to fall back to using server-side communication.

Privacy

Do you collect personally-identifiable information about the participants of my share sessions?

We never collect or retain any personally identifiable information about any of your share session participants, whether they are a presenter or a viewer. Our API has no concept of user accounts so we have no information that can tie a specific viewer to a person. We do use the IP address of the presenters to help route a share session to our closest servers, but an IP address is not considered personally identifiable information. Even so, we do not store the presenter IP address once we have used it for selecting the optimal server to service the share session.

We also do not retain any information that is shared through our service on any permanent media such as a hard disk or tape drive. All data is only retained in volatile memory that is purged within one minute of the end of a share session.

Is there a way that I can pre-install the Mac app for all the users that I manage?

Yes, if you administer the computers for your company, you can pre-install the Mac app on each of your user's computer by downloading the installation script at http://www.screenleap.com/installer/mac.

After downloading the installation script, you will need to copy the script to the administered computer and then run the following from the directory where the installation script was copied to:

chmod +x screenshare_installer.sh ./screenshare_installer.sh
/api/faq
OK
OK
OK
...