|
2 | 2 | pcx_content_type: navigation |
3 | 3 | title: Getting Started |
4 | 4 | sidebar: |
5 | | - order: 3 |
6 | | - hidden: true |
7 | | ---- |
| 5 | + order: 4 |
| 6 | +--- |
| 7 | +import { Tabs, TabItem, Steps, Render } from '~/components'; |
| 8 | + |
| 9 | +:::note[Before you get started with RealtimeKit:] |
| 10 | + |
| 11 | +If you don't have a Cloudflare Account, [please create one](/fundamentals/account/create-account/). |
| 12 | + |
| 13 | +::: |
| 14 | + |
| 15 | +### Understanding the RealtimeKit SDK Model |
| 16 | + |
| 17 | +Before we get started with RealtimeKit, let's understand the SDK model. |
| 18 | + |
| 19 | +In RealtimeKit, the concepts of [**meeting**](/realtime/realtimekit/concepts#meeting) and [**participant**](/realtime/realtimekit/concepts#participant) serve as blueprints—these are database entries that define the structure and roles for real-time interactions. A meeting blueprint outlines the configuration for a collaborative space (such as a classroom, telehealth appointment, or webinar), while a participant blueprint defines the roles and permissions available within that space. |
| 20 | + |
| 21 | +When it comes to real-time usage, these blueprints are instantiated as sessions and peers: |
| 22 | +- A [**session**](/realtime/realtimekit/concepts#session) is a live instance of a meeting, representing an active, real-time interaction. |
| 23 | +- A [**peer**](/realtime/realtimekit/concepts#peer) is a live instance of a participant—an actual user (such as a teacher, student, doctor, or patient) joining the session. |
| 24 | + |
| 25 | +> **Note:** In some contexts, the terms **session** and **meeting**, as well as **peer** and **participant**, are used interchangeably. This is because most people are more familiar with the terms "meeting" and "participant." However, in RealtimeKit, using "session" and "peer" helps differentiate between live instances (sessions and peers) and their blueprints (meetings and participants), making it easier to track and manage them individually in the RealtimeKit dashboard. |
| 26 | +
|
| 27 | +The SDK is always initialized from the perspective of a peer joining a session. Each peer’s capabilities and permissions are determined by the participant blueprint and the assigned preset (role configuration) you defined during setup. |
| 28 | + |
| 29 | +This design means: |
| 30 | +- Every SDK instance represents a single peer (runtime participant) in a specific session (runtime meeting). |
| 31 | +- The peer’s role (e.g., teacher, student, doctor, patient) is established when generating their authentication token, based on the participant blueprint and preset. |
| 32 | +- The SDK enforces permissions and features according to the preset, without distinguishing between participant types at the API level. |
| 33 | +- This approach allows you to create sessions where diverse roles (like instructors and students, or doctors and patients) can interact with tailored capabilities, all based on their blueprint definitions. |
| 34 | + |
| 35 | +In summary, think of meetings and participants as templates or blueprints, and sessions and peers as their real-time, live counterparts. Each client (browser, device, or app) initializes the SDK as a peer, using an auth token that encodes their permissions and role for that session. |
| 36 | + |
| 37 | +To put this model into practice, you’ll follow these steps: |
| 38 | + |
| 39 | +1. **Create an API token** with Realtime permissions. |
| 40 | +2. **Create an RealtimeKit App** to logically organize and manage your meetings. |
| 41 | +3. **Create a Meeting** within the app, which acts as a blueprint for a real-time session. |
| 42 | +4. **Add a Participant** and generate an authentication token for the peer who will join the session. |
| 43 | +5. **Initialize the SDK** using the participant’s auth token. |
| 44 | +6. **Join the session as a peer**—enabling real-time interaction with others in the meeting. |
| 45 | + |
| 46 | +### Create Cloudflare API access Token with Realtime Permissions |
| 47 | + |
| 48 | +To integrate RealtimeKit in your application, you must have a Cloudflare API token with **Realtime** access permissions. To create an API token: |
| 49 | + |
| 50 | +1. Follow the [Create API token guide](/fundamentals/api/get-started/create-token/) to create a new token via the Cloudflare dashboard |
| 51 | +2. When configuring permissions, ensure you include **Realtime** access |
| 52 | +3. Configure any additional [access policies and restrictions](/fundamentals/api/reference/permissions/) as needed for your use case |
| 53 | + |
| 54 | +Alternatively, you can [create tokens programmatically via the API](/fundamentals/api/how-to/create-via-api/) if you prefer automation. |
| 55 | + |
| 56 | +Make sure to select the Realtime product with Admin access. |
| 57 | + |
| 58 | +. |
| 59 | + |
| 60 | +If done right, following CURL should give you the list of you existing apps with 200 status code. If you have no apps, it will return an empty array with 200 status code. |
| 61 | + |
| 62 | +```bash |
| 63 | +curl --location 'https://api.cloudflare.com/client/v4/accounts/<account_id>/realtime/realtimekit/kit/apps' \ |
| 64 | +--header 'Authorization: Bearer <api_token>' |
| 65 | +``` |
| 66 | + |
| 67 | +If the above API doesn't give you 200 status code, it means you don't have the right permissions or the API token is not valid. |
| 68 | + |
| 69 | +You can also view and manage your apps directly in the [Cloudflare RealtimeKit dashboard](https://dash.cloudflare.com/?to=/:account/realtime/realtimekit/kit). |
| 70 | + |
| 71 | +### Create RealtimeKit App |
| 72 | + |
| 73 | +Once you have your API token ready, the next step is to create a RealtimeKit app. |
| 74 | +You can use our [API reference](/api/resources/realtimekit) for details on creating an app, or use the following sample cURL command: |
| 75 | + |
| 76 | +```bash |
| 77 | +curl --location 'https://api.cloudflare.com/client/v4/accounts/<account_id>/realtime/realtimekit/kit/apps' \ |
| 78 | +--header 'Content-Type: application/json' \ |
| 79 | +--header 'Authorization: Bearer <api_token>' \ |
| 80 | +--data '{ |
| 81 | + "name": "My First RealtimeKit App" |
| 82 | +}' |
| 83 | +``` |
| 84 | + |
| 85 | +For more about apps and their role, see the [RealtimeKit Concepts guide](/realtime/realtimekit/concepts). |
| 86 | + |
| 87 | +#### Sandbox vs Production App |
| 88 | + |
| 89 | +It’s best practice to create separate apps for your production and staging environments. This helps you test changes safely without impacting your live environment. |
| 90 | + |
| 91 | +For example, you might name your staging app as `<company_name> - <product_name> - staging` and your production app as `<company_name> - <product_name> - production`. |
| 92 | +You are free to choose any app name that fits your workflow. |
| 93 | + |
| 94 | +### Create Meeting |
| 95 | + |
| 96 | +After creating an app, you can create a new meeting. |
| 97 | +Refer to the [API reference](/api/resources/realtimekit) for endpoint details. |
| 98 | + |
| 99 | +```bash |
| 100 | +curl --location 'https://api.cloudflare.com/client/v4/accounts/<account_id>/realtime/realtimekit/kit/<app_id>/meetings' \ |
| 101 | +--header 'Content-Type: application/json' \ |
| 102 | +--header 'Authorization: Bearer <api_token>' \ |
| 103 | +--data '{ |
| 104 | + "title": "My First RealtimeKit Meeting", |
| 105 | +}' |
| 106 | +``` |
| 107 | + |
| 108 | +To verify your meeting, you can list all meetings for your app: |
| 109 | + |
| 110 | +```bash |
| 111 | +curl --location 'https://api.cloudflare.com/client/v4/accounts/<account_id>/realtime/realtimekit/kit/<app_id>/meetings' \ |
| 112 | +--header 'Authorization: Bearer <api_token>' |
| 113 | +``` |
| 114 | + |
| 115 | +Be sure to keep the ID of your newly created meeting for the next steps. |
| 116 | + |
| 117 | +### Create a Preset for a Participant |
| 118 | + |
| 119 | +Before adding participants, you need to decide what permissions they should have. |
| 120 | +Presets define these permissions, and RealtimeKit provides some default presets to get you started. |
| 121 | +Learn more about presets in the [Concepts guide](/realtime/realtimekit/concepts#presets). |
| 122 | + |
| 123 | +To see existing presets, use: |
| 124 | + |
| 125 | +```bash |
| 126 | +curl --location 'https://api.cloudflare.com/client/v4/accounts/<account_id>/realtime/realtimekit/kit/<app_id>/presets' \ |
| 127 | +--header 'Authorization: Bearer <api_token>' |
| 128 | +``` |
| 129 | + |
| 130 | +You can create new presets using the [API reference](/api/resources/realtimekit) or via the [RealtimeKit dashboard](https://dash.cloudflare.com/?to=/:account/realtime/realtimekit/kit). |
| 131 | + |
| 132 | +Keep the preset name handy for the next step. |
| 133 | + |
| 134 | +:::note |
| 135 | +**Presets can be reused across multiple meetings.** |
| 136 | + |
| 137 | +This means you can define a role (such as "teacher" or "viewer") once and assign it to participants in any number of meetings, ensuring consistent permissions and experience. For example, the same `teacher` preset can be used for all classrooms, so you don’t have to redefine permissions every time you create a new meeting. This streamlines setup and helps maintain standardized roles across your organization. |
| 138 | +::: |
| 139 | + |
| 140 | +### Add Participant |
| 141 | + |
| 142 | +With your meeting and preset ready, you can now add a participant. |
| 143 | +Replace all placeholder values in the following cURL command with your actual data. |
| 144 | + |
| 145 | +```bash |
| 146 | +curl --location 'https://api.cloudflare.com/client/v4/accounts/<account_id>/realtime/realtimekit/kit/<app_id>/meetings/<meeting_id>/participants' \ |
| 147 | +--header 'Content-Type: application/json' \ |
| 148 | +--header 'Authorization: Bearer <api_token>' \ |
| 149 | +--data '{ |
| 150 | + "name": "Mary Sue", |
| 151 | + "preset_name": "<preset_name>", |
| 152 | + "custom_participant_id": "<any_uuid_to_identify_participant>" |
| 153 | +}' |
| 154 | +``` |
| 155 | + |
| 156 | +**Field explanations:** |
| 157 | +- `name`: The display name of the peer. This can be any string and will be shown to other peers in the live session of a meeting. |
| 158 | +- `preset_name`: The name of the preset you created or selected earlier. This determines the permissions and capabilities assigned to the participant. |
| 159 | +- `custom_participant_id`: A unique identifier for the participant within this meeting. If you call the Add Participant API again with the same `custom_participant_id` for the same meeting, RealtimeKit will not create a duplicate participant but will instead return the existing participant's token. This can be any unique string, such as a UUID. **Do not use email addresses or personally identifiable information (PII)** here to proactively avoid sharing sensitive details. This UUID will be available in SDK for you to use later on. |
| 160 | + |
| 161 | +The response will include an auth token, which is required for the participant to join the meeting. |
| 162 | +See the [API reference](/api/resources/realtimekit) for more details on participant management. |
| 163 | + |
| 164 | +### Try the RealtimeKit Sample UI with Participant Auth Token |
| 165 | + |
| 166 | +Now that you have the auth token, you can try out the default UI samples for different platforms. Choose your platform below: |
| 167 | + |
| 168 | +<Tabs> |
| 169 | +<TabItem label="React"> |
| 170 | + |
| 171 | +**Run the default-meeting-ui sample ([GitHub repo](https://github.com/dyte-io/react-samples/tree/main/default-meeting-ui))** |
| 172 | + |
| 173 | +1. Clone the sample: |
| 174 | + ```bash |
| 175 | + git clone https://github.com/dyte-io/react-samples.git |
| 176 | + cd react-samples/default-meeting-ui |
| 177 | + ``` |
| 178 | +2. Install dependencies: |
| 179 | + ```bash |
| 180 | + npm install |
| 181 | + ``` |
| 182 | +3. Start the development server: |
| 183 | + ```bash |
| 184 | + npm start |
| 185 | + ``` |
| 186 | +4. Open the app in your browser. To join the session, **append your auth token to the preview URL**: |
| 187 | + ``` |
| 188 | + http://localhost:3000/?authToken=<participant_auth_token> |
| 189 | + ``` |
| 190 | + Replace `<participant_auth_token>` with the token you received from the Add Participant API. |
| 191 | +</TabItem> |
| 192 | +</Tabs> |
| 193 | + |
| 194 | +:::note |
| 195 | +If there isn’t an active session for your meeting, initializing the SDK with a valid auth token will automatically create a new session for you. |
| 196 | +::: |
| 197 | + |
| 198 | +Feel free to explore additional sample applications and use cases on our [GitHub](https://github.com/dyte-io). These resources can help you further experiment and accelerate your integration with RealtimeKit. |
0 commit comments