Once created, use one of our client-side Video SDKs for iOS, Android, or JavaScript to connect to DailyStandup and get your users talking.
Default Room Settings
The new REST API is great when you want to dynamically control Room configuration. Many applications, however, use the same settings for every Room. And sometimes, you want to be able to experiment with different options during development without having to make a REST API request each time.

We’ll use the defaults you configure here whenever a new Room is created in your Twilio account, unless you override the defaults when creating a Room through the REST API.
Room-based access control
Another new feature, Room-based access control, gives you more control over the security of Programmable Video Rooms. Now, when you generate a client’s Access Token, you can add an optional room grant. The client that uses this token to connect to Programmable Video will only be allowed to connect to the exact Room you’ve specified in the grant.
For example, to generate an Access Token that lets the client connect to the room DailyStandup using our JavaScript helper library, you’d do the following:
Check out our docs to learn more about Access Tokens and Room Access Control.
Client-side Room creation
When Client-side Room creation is enabled, it’s easy to get up and running without writing any back-end code:
- Any SDK client that holds a valid Access Token can create a new Video Room without you needing to first call the REST API.
- The client can specify the Room’s name, and if the Room doesn’t exist it will be created on-the-fly.
When you’re done prototyping and ready to move your app to production, you can disable client-side Room creation, which will mean:
- A client’s Access Token must contain a video grant for a specific Room in order to connect.
- The Room must be pre-created with the REST API.
Goodbye Configuration Profiles
Before the REST API and Default Room Settings, Room configuration was governed by the Configuration Profile you set in your Video client’s Access Token. The Rooms REST API and Default Room Settings are simpler solutions, so we are deprecating support for multiple Configuration Profiles in favor of this REST API.
This means the following:
- Effective today, you can still view your existing Configuration Profiles, but you won’t be able to edit them or create new ones.
- Apps that use Configuration Profiles will continue working exactly as they do today until August 1, 2017.
- On August 1, 2017 we’ll remove Configuration Profile support from the Video product. On this date, the Default Room Settings configured in your account will be used for any Rooms that are not created through the REST API.
Using an older release of the Video SDKs?
If you’re using an earlier release of our Video SDKs, you’re likely wondering “How do these changes affect my app?”.
If you’re using 1.0.0-beta1 or 1.0.0-preview1 or greater of our Video SDK, your application will continue to function without modification. All of the changes mentioned above are backwards compatible with earlier releases of our Video SDKs, and your app will continue working exactly as it does today. You only need to take note of the deprecation of Configuration Profiles on August 1, 2017 and make sure you have your Default Room Settings configured correctly.
If you’re using a release of our Video Conversations SDK (releases older than 1.0.0-beta1 or 1.0.0-preview1), back-end support for these SDKs will be terminated on August 1, 2017. There are only a very small number of applications still using these early releases of our Video SDKs, so chances are you don’t need to worry.
The Video Conversations SDK releases impacted by this change are the following:
- Conversations Android 0.12.2 and earlier
- Conversations iOS 0.25.1 and earlier
- Conversations JavaScript 0.13.10 and earlier
If you have any questions about any of these changes, don’t hesitate to reach out to our team at support@twilio.com. We’d be happy to give you a hand with any of your Programmable Video questions.
SDK versioning and distribution
And as a reminder, our Programmable Video SDKs follow standard semantic versioning. In summary, this means that given a version number MAJOR.MINOR.PATCH, we will increment the:
- MAJOR version when we make incompatible API changes.
- MINOR version when we add functionality in a backwards-compatible manner.
- PATCH version when we make backwards-compatible bug fixes.
Additionally, we denote Developer Preview or Beta releases by appending -preview or -beta metadata to future releases.
If you’re an iOS developer using CocoaPods, this also means you should now consume iOS SDK releases directly from the CocoaPods Master Spec Repository. Make sure you update your Podfile in order to keep up to date with future iOS releases.
To start receiving updates from the CocoaPods directory, modify your Podfile as follows:
Video everywhere
We believe that technical and consumer trends are making embedded, in-app voice & video a must-have capability for many applications.
The global adoption of mobile devices means that we’re all carrying an incredible camera, microphone, and CPU in our pocket. Widespread support for WebRTC means that billions of people now use a video-capable browser to access the internet every single day. And increasing wireless network bandwidth and reliability makes it possible to bring high quality video to all kinds of environments that were previously unreachable.
We can’t thank you enough for participating in the Programmable Video Beta. We look forward to meeting you face-to-face, hearing your feedback, helping you with your app development, and sharing our roadmap.
We can’t wait to see you what you’ll build with Programmable Video!