API

Frequently Asked Questions

User Experience

Integration

Technical: Managing Screen Shares

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 screen share console will have your company name in the title bar - not Screenleap. They can launch the screen share 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?

The user who is sharing his/her screen needs to either install one of the desktop apps for Windows and Macs, or install the Screenleap browser extension for Chrome. The users who view the screen share don't need anything more than a web browser! See the API Introduction for more details about Requirements.

Integration

How do I show the instructions with the link to manually start the screen share 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 screen share 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 screen share, 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.

Technical: Managing Screen Shares

How can I close out users who leave their screen shares open for too long?

The best method is to make a call to the API to stop the screen share. 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 API call is preferred.

Can I have multiple concurrent screen shares running at the same time?

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

Can I reuse a share code for a new session?

Once a screen share ends, you cannot use the share code again. This is because the screen share duration is calculated from the time the presenter app first connects to the time the presenter app gets closed. If we allowed screen shares to be re-opened, then you would be charged for the entire duration, including the period when the screen share wasn't running.

We do allow a screen share 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 intentially 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 screen share to be reopened for five minutes after the screen share ends.

How can I implement presenter swap using the API?

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

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 screen share is successfully started. If we detect the presence of the cookie on a subsequent screen share, 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.

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

No. When you make the screen share, 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 screen shares in advance and try to use them later, your HTML might be outdated.

If the purpose of making screen 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 screen share 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 screen share.

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 screen share 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 screen share ended, and to pass along some info about the screen share 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 screen share 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 screen share ends, there may be a delay of several minutes. (For example, if the presenter loses their internet connection, we hold the screen share open a few minutes to see if the connection comes back before closing it out.) See the API Reference for Making a new screen share request for more information.

Billing and Time

How is the duration of the screen share calculated?

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

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

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

  • The user clicks the Stop button.
  • The app receives an API call to stop the screen share. See Stop an active screen share 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 screen share. 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 screen shares this month, as well as how many free credits remain.

I was testing out the API and accidentally left open a screen share, 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 screen share?

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

We are currently working to add support for recording. It should be available in the next few months.

Implementation

Under what conditions will the integration attempt to start the screen share 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 screen share using the local web server. If it fails, then we attempt to start the screen share using the custom protocol handler. We do this because it gives the user a better screen share experience to start the screen share 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 screen share 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 screen share?

Verify that your initial request for a screen share 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 screen shares 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 screen share. 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 screen shares?

We never collect or retain any personally identifiable information about any of your screen share 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 screen share 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 screen share.

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 screen share.

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
...