Skip to content

Commit c4df2ca

Browse files
docs(realtimekit): added getting starteddocs
1 parent fa0dc9d commit c4df2ca

File tree

3 files changed

+202
-3
lines changed

3 files changed

+202
-3
lines changed
45.2 KB
Loading

src/content/docs/realtime/realtimekit/concepts.mdx

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,14 @@ sidebar:
77

88
This page explains the core concepts and terminology used in RealtimeKit.
99

10+
### Apps
11+
12+
An **App** serves as a container for your RealtimeKit application, logically organizing related meetings and participants.
13+
14+
For example, if you are building an interview platform, you might create two apps: `<company_name> - interviews - staging` and `<company_name> - interviews - production`. If you later decide to build an assessment platform, you could similarly create `<company_name> - assessments - staging` and `<company_name> - assessments - production`.
15+
16+
This structure helps you manage meetings and participants in a clear, organized manner.
17+
1018
### Meeting
1119

1220
A **Meeting** is the fundamental communication channel in RealtimeKit. You can think of it like an event on your calendar - it's a persistent, long-lived container or "room" that serves as a blueprint for its [sessions](/realtime/realtimekit/concepts/#session). Every session created for this meeting inherits the same base configuration, such as the title of the meeting and whether to automatically record the session when it starts. You add participants to the meeting, which grants them access to join a session of that meeting.

src/content/docs/realtime/realtimekit/getting-started.mdx

Lines changed: 194 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,197 @@
22
pcx_content_type: navigation
33
title: Getting Started
44
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+
![Realtime permission token section](~/assets/images/realtime/realtimekit/permission-token-section.png).
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

Comments
 (0)