Documentation

The goal for this page is to give you some simple insights that we believe are best practices.

While this is not something important only to those that create integrations, it is something that integration should be more aware of.

Do

Private key as well as encrytion tokens are something you should keep private. This allows our system to know that it is really you who is making a request.

Use these on your servers to receive the data you need and then show it or pass it to your web or client apps for preview.

Don't

It seems very interesting to add one or both of the tokens into your mobile apps. This however makes it really easy for someone to grab the tokens from the code of your app. Unlike application token, these are designed to be used only by yourself and should only be used on server side.

Do

Some setups might require Flash specificailly however if it does not, it is always best to use WebRTC. WeBRTC allows more parameters to be possible to use. It also offers better UX as there are not as many requirements for underlaying system.

We recommend using webrtc_for_mobile and webrtc_streaming_if_necessary in your application setup.

Don't

Setting up the integration to not use WebRTC means that your integration depends on Flash to be installed as well as properly installed and up to date. For mobile this means that native camera apps will always be used which means many parameters will not be accepted by the same.

Do

Clone and the star or watch the repository. It will allow you to keep up to date with any new changes and releases to the same. This will offer you easiest way to know when something happens so that your integration can be updated accordingly.

Git allows you to keep track of where the repository is and GitHub offers you the watch and star features.

Don't

Download the SDK to use the feature without having any reference as from where or without watching/staring it. While it will work and allow you to make your integration, it will keep you out of the loop on new changes, including any security or stability releases.

Do

Our system offers the use of tags such as "stable" and "latest" as well as revision. The tags allow you to have our backend bring updates without you changing the revision manually.

We recommend using "stable" tag, or if you will be updating your plugin often, you can use a specific revision that you test against.

  • The "stable" tag points to resources that are in use by most of our customers in production. While all revisions are stable when we release them, this is the most used and tested one.

If the later, you should at least look at our Twitter Dev account to know when new revision is released.

Don't

"latest" tag means that your integration is using the very latest of features. While our tests showed it as stable to be released, it will be updated from time to time and might bring some unexpected things to happen in specific setups.

This would not be the recommended for production version of the integration.

This applies even more specifically to the use of specific revision or dev-preview releases.

The next step would be to get familiar with our branding policies if you did not already. Also it will provide you with assets and info that you can download right away and use.

You can get to the branding guidelines by clicking here.