What embedding Jitsi Meet in your own portal involves
A team that wants video meetings launched from its own portal or application should use the Jitsi IFrame API. The supported method is the IFrame API, loaded from your own domain at https://<your-domain>/external_api.js and used by creating a JitsiMeetExternalAPI(domain, options) object. Applications built with React should use the Jitsi React SDK instead, which the Jitsi handbook points to for that stack. Both approaches only work once a self-hosted Jitsi Meet is running on infrastructure you control, because the script and the conference services it talks to must come from the same deployment as your portal.
The IFrame API works on mobile browsers the same way it works on desktop, so the portal does not need a separate embedding path for phones and tablets. Meetings on a custom server can also be opened in the Jitsi Meet mobile app through the org.jitsi.meet URL scheme on iOS and an Android intent URL, which is useful when a user should leave the browser and join in the app. Confirm with your own testing which device and browser combinations your users rely on, since the handbook describes general behavior rather than a test matrix for your environment.
This section sets the scope for the rest of the page. The following sections cover the self-hosted prerequisites that the embedding depends on, the options object and the events your portal can listen to, how the portal passes room names and user details into the meeting, and what changes compared with embedding the public meet.jit.si service. Read this section first if your team has only embedded meet.jit.si before, because several assumptions that work on the public instance do not carry over.
The decisions to make early are the domain the script is served from, how the portal authenticates users before they reach a room, and who owns the deployment that the portal calls. Each of these affects the work your own team or a partner must plan. Ask whoever runs your Jitsi Meet deployment to confirm the domain name, the certificate in place for it, and whether room creation is open to anyone with a link or restricted by token, because the embedding code reads and depends on all three.
What must be in place before you embed
Embedding depends on a working self-hosted Jitsi Meet deployment that your portal can reach over HTTPS. The cards below cover the platform, the certificate, the network ports, the browser security settings and the authentication decision, in the order most teams need to settle them.
A working self-hosted Jitsi Meet stack
Before you write any embedding code, confirm that a complete Jitsi Meet deployment works on its own: a web server (nginx or Apache) serving the web app, the Prosody XMPP server, Jicofo as the conference focus, and one or more Jitsi Videobridge media routers. The Debian/Ubuntu quick start targets Debian 12 or newer and Ubuntu 24.04 or newer with OpenJDK 17, while the official Docker setup runs these as separate containers. Pick one installation method and confirm the supported versions in the Jitsi handbook and the jitsi-meet repository before you build on them.
A valid HTTPS domain certificate
The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video. Self-signed certificates cause problems, especially with mobile clients, so a certificate from a trusted authority for the exact hostname your portal will load must be installed before embedding. Check that the certificate chain is complete and that the hostname in your portal matches the hostname on the certificate, because a mismatch will break the external_api.js load silently in some browsers.
Open network ports and firewall rules
The Debian/Ubuntu quick start requires 80/TCP and 443/TCP for the web interface and 10000/UDP for media traffic from the videobridge. Port 5349/TCP provides TCP fallback for clients that cannot reach UDP, and 3478/UDP supports STUN; both are optional but should be decided up front for users on restrictive networks. Confirm these rules with your network team at the perimeter and on any host firewall, and check that the same ports are reachable from the users' networks, not only from your office.
Portal origin and content security policy
The page that hosts the embed loads external_api.js from your Jitsi domain and opens an iframe to it, so your portal's Content Security Policy must allow scripts from the Jitsi host and frames from the same host. Record the exact origin of your portal and the Jitsi domain, including any subdomains, and add them to the policy before testing. Also confirm the allowed origins on the Jitsi side so that only your portal can host the embed, and review how your CSP changes are approved, since a loose frame-src rule can widen what other sites can embed.
Authentication model chosen in advance
Decide how room creation will be controlled before embedding, because the answer changes the configuration on both sides. The Jitsi handbook marks the older secure domain method (username and password room creation) as deprecated for new installations and recommends JWT token authentication, with a separate anonymous domain for guests. The Docker guide also lists internal XMPP accounts, LDAP, Matrix user verification and a hybrid mode. Your portal must generate tokens or pass the right options, so settle this model with your identity owner first, then confirm the current options in the token authentication page of the handbook.
How the IFrame API loads and joins a room
The embedding flow starts when your portal page loads external_api.js from your own Jitsi domain, in the form https://<your-domain>/external_api.js. The script exposes a JitsiMeetExternalAPI constructor. Your portal calls it with a domain and an options object, and the API creates an iframe inside the page and connects that frame to a conference on your server. Because the script is served from your deployment, the browser must trust the domain certificate. The Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video and warns that self-signed certificates cause problems. Confirm the script path for your release before you wire it into a build.
The options object decides three things: which room opens, which page element holds the frame, and how large the frame is. The room name is the value your portal controls most directly, so decide before build time how room names are generated and whether users can choose them. The container and size settings govern layout, and they need testing on narrow screens if the portal is responsive. Option names and the events the API emits are the parts most likely to differ between Jitsi Meet releases. Check the handbook's IFrame API page for your version, and rerun the embedding test after every upgrade so that a renamed option does not go unnoticed.
Once the frame loads, the conference runs on your infrastructure. Prosody handles XMPP signaling, Jicofo acts as the conference focus, and the videobridges route encrypted audio and video between participants. The portal controls the embedding and the user context it passes in, such as a display name or identity data when your authentication setup uses it. It does not carry media, and it does not decide who holds moderator rights unless your chosen authentication method makes that decision. Plan network reachability for the portal's users as you would for direct meeting users, since they must reach the media ports listed in the quick start guide, including 10000/UDP.
The handbook points React applications to the Jitsi React SDK instead of raw script calls, so a React portal should evaluate the SDK first. Use direct script calls where the SDK does not fit your architecture, and document which path you chose so that upgrades are planned against the right API. The handbook also says the IFrame API works on mobile browsers the same way it works on desktop. Opening meetings in the Jitsi Meet mobile app on a custom server uses a separate mechanism, the org.jitsi.meet URL scheme on iOS and an Android intent URL. Build a test plan that covers desktop and mobile browsers and the native app before the portal goes live.
Setup sequence for the IFrame API embed
This sequence takes a self-hosted Jitsi Meet instance from a working HTTPS domain to a meeting embedded in your own portal, with checks at each stage. Each step closes with a verifiable result, so your team can confirm the embed works before exposing it to users.
Confirm HTTPS on your domain
Your platform or infrastructure team confirms that the self-hosted Jitsi Meet instance is served over HTTPS on the domain your portal will use, with a certificate issued by a trusted authority for that name. The Jitsi handbook states that a proper domain certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. Check it by loading the instance in a desktop browser and on a phone, then confirming there are no certificate warnings and the lobby page loads. Do not continue until both devices show a clean connection.
Verify the external API script loads
Your front-end developer requests https://<your-domain>/external_api.js directly in a browser and confirms the server returns the JavaScript file rather than an error page. The IFrame API is loaded from this path on a self-hosted deployment, so the portal depends on it being reachable from the networks your users work on. Check it by loading your portal test page and confirming the browser console shows the script loaded without a blocked request or certificate error, and that the JitsiMeetExternalAPI constructor is defined.
Choose identity and configure JWT authentication
Your identity and security owners decide how room names are generated, who may create rooms, and which users are moderators. The Jitsi handbook recommends JWT token authentication over the deprecated secure domain method for new installations, and it recommends a separate anonymous domain for guests. Your team configures the token issuer, audience and signing secret in the deployment, then checks the result with a test token. Confirm that a token signed with the correct secret joins as a moderator, and that a token with a wrong signature or missing claims is refused.
Create the portal page and API object
Your front-end developer adds a page to the portal, loads the external API script, and creates a JitsiMeetExternalAPI object with your domain as the first argument and an options object as the second. The options typically include the room name, the parent element for the embed, and any user details that your token flow requires. Your developer confirms the meeting appears inside the container and that the room name matches the one generated by your portal. Check it by opening the page with two test accounts and confirming both reach the same room.
Set container sizing and device permissions
Your front-end developer sets the size of the container element so the video grid has room on desktop and on small screens, and adds the iframe allow attribute so the browser grants camera, microphone and screen sharing to the embedded meeting. Without that attribute, the embedded page may not receive device access even though the browser has granted it to your portal. Check it by joining from inside the portal, granting permissions when prompted, and confirming that local camera and microphone preview and remote audio and video work.
Test desktop and mobile browsers
Your QA team runs the same join scenario on the browsers your users rely on, both desktop and mobile. The Jitsi handbook says the IFrame API behaves on mobile browsers the same way as on desktop, but your own portal layout, permission prompts and token flow can still differ by device. Include a guest join through the anonymous domain, a moderator join, and a screen share. Check it by recording a result for each browser and device pair, and do not sign off until audio, video and screen sharing work in both directions for every pair you support.
Decide on mobile app handoff
Your product owner and engineering lead decide whether users should be handed from the portal to the Jitsi Meet mobile app. The handbook documents opening a meeting on a custom server in the app with the org.jitsi.meet URL scheme on iOS and an Android intent URL. Confirm that the installed app uses your server, since a meeting link alone may not select it, and decide what happens when the app is not installed. Check it on a test iOS device and a test Android device by tapping the handoff link and confirming the meeting opens in the app against your domain.
How portal identities and room data map to Jitsi
This table pairs each portal field with its Jitsi target, the team that should own the decision, and what to confirm in the token authentication handbook. Read it as a checklist for the integration design: each row is a decision to settle before the IFrame code is written. The main takeaway is that the claim structure and the guest path are version-specific, so the handbook for your release is the final reference.
| Source field | Jitsi target | Owner and what to confirm |
|---|---|---|
| Portal user account | Display name shown in the meeting | Product owner sets which name field is used. Confirm in the token authentication handbook which user attributes can be carried in the token. |
| Portal user role (host or attendee) | Moderator or guest role in the room | Security and product owners agree who may moderate. Confirm the exact claim structure for moderator status in the handbook for your version. |
| Meeting record ID or slug | Room name in the meeting URL | Platform engineer defines a naming rule that is unique and unguessable. Confirm room name character limits and encoding in the IFrame API documentation. |
| Portal roles and permissions | JWT claims in the signed token | Identity or security team maps roles to claims. Confirm the exact claim names, required fields and signing settings in the handbook for your release, since names are not assumed here. |
| Token issuer and audience settings | Prosody token validation settings | Platform engineer matches the issuer, audience and app identifier configured on the server. Confirm each value against the handbook section for your version. |
| Guest or external invitee | Anonymous domain access without a token | Security owner decides whether guests may join and under what conditions. Confirm how the anonymous domain is configured and which features guests lose. |
| Meeting lifetime and end time | Room lifecycle and token expiry | Product owner and platform engineer set expiry rules. Confirm how token expiry and wait-for-host behave in the handbook for your version. |
What changes from embedding meet.jit.si
The first change is the domain. The public instance is loaded from meet.jit.si, so the snippet you may have copied from an example points there in two places: the script that loads external_api.js and the first argument passed to JitsiMeetExternalAPI(domain, options). On a self-hosted deployment both must name your own host, and the script is served from https://<your-domain>/external_api.js. Check every copy of the embed in your portal, mobile wrappers and documentation, because a stale hostname will keep sending users to the public service or to a page that fails to load.
Second, your own infrastructure has to be reachable and trusted by every browser that opens a meeting. The Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. Confirm that the web server certificate chains to a trusted authority for your users, that ports 80/TCP, 443/TCP and 10000/UDP are open to the internet or to the networks your users sit on, and that 5349/TCP is available as the TCP fallback. Test from a corporate network that restricts UDP, because that is where embedded meetings most often fail.
Third, authentication is a decision you now own. The public instance is not configured to your identity model, so anyone with the link can typically join and the embedding page cannot assert who the user is. On your own deployment you choose how room creation is controlled. The handbook marks the older secure domain method as deprecated for new installations and recommends JWT token authentication, with a separate anonymous domain for guests. Decide which users may create rooms, how your portal passes identity into the token, and what guests see, before you publish the embed. Reconsider this choice if your portal will carry regulated or confidential meetings.
Fourth, plan capacity and features for your own estate. The scalable setup guide says videobridges scale horizontally by adding more, and it suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge, while warning that scalable infrastructure is not a task for beginning administrators. Recording depends on Jibri, which runs Chrome in a virtual framebuffer, supports one recording at a time on a single Jibri, and should run on its own machine or VM. Optional extensions such as Etherpad, Excalidraw and Jigasi transcription are not present unless you deploy and configure them. Ask your team to confirm each feature your portal relies on against the release you install.
Finally, uptime and upgrades become your responsibility. Stable releases are tagged by build number, such as stable/jitsi-meet_11248, and your portal's embed depends on the API your server exposes, so each upgrade needs a test of the embed. For comparison, 8x8 offers JaaS (Jitsi as a Service), a managed service run by the team that builds Jitsi, and meet.jit.si is its free public instance. The two models differ in who operates the servers, certificates, scaling and upgrades, and in who is paid for that work. Compare them with your own requirements in writing before you commit, because moving between them later means changing domains, tokens and the embed again.
Security settings for an embedded Jitsi Meet
An embedded Jitsi Meet inherits the trust decisions of the page that hosts it, so room creation, guest access, certificates and framing all need to be set deliberately. The cards below cover the controls that matter most when the IFrame API is the entry point, and the encryption limits your users should understand before you describe the service to them.
Enforce token-based room creation
Token authentication lets your portal decide who can open a room. Your server signs a JWT with the room name, user identity and moderator flag, and Prosody verifies that token before Jicofo creates the conference. Check that anonymous users cannot create rooms on the main domain, and test that a request without a valid token is rejected rather than silently joined as a guest.
Avoid the secure domain method
The secure domain method, which relies on a username and password for room creation, is marked deprecated in the Jitsi handbook for new installations. If you are starting from scratch, configure JWT token authentication instead. If an existing deployment still uses secure domain, plan its migration to tokens as a separate change with its own test window, because the two methods interact with how moderators join.
Isolate guest access on the anonymous domain
The Jitsi handbook recommends a separate anonymous domain for guests so that unauthenticated participants are kept apart from the authenticated main domain. Confirm which domain your embed points to for each user type, and check that guests cannot reach moderator functions or rooms reserved for authenticated users. Document the naming of both domains so that support staff can tell them apart during incidents.
Use valid TLS certificates on every host
The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and warns that self-signed certificates cause problems, especially on mobile clients. Use certificates from a publicly trusted authority or from your internal CA that your users' devices already trust. Set renewal reminders, and confirm that the certificate covers the exact domain your IFrame API script loads from.
Restrict the origins allowed to host the frame
Limit which websites can embed the meeting so that an attacker cannot place your Jitsi instance inside a page they control. Define the allowed origins in your portal's Content Security Policy frame-ancestors directive and in the Jitsi web server configuration. Test the embed from each approved origin and from an unapproved one, so you know the block works and that legitimate pages still load.
Understand what end-to-end encryption covers
Jitsi encrypts audio and video on the network with DTLS-SRTP, and the videobridge decrypts packets in memory while routing them without storing them. End-to-end encryption is available only in Chromium 83 or later browsers and the Jitsi Electron client, and it covers audio, video and screen sharing but not chat or polls. Tell users which clients support it, and confirm with your compliance owner whether the transport encryption alone meets your requirements.
Mobile clients and opening meetings in the Jitsi Meet app
The Jitsi IFrame API behaves the same on mobile browsers as it does on desktop, so the embedding code you build for your portal does not need a separate mobile version. The experience around it is different, though. Phones have smaller screens, their own permission prompts for camera and microphone, and stricter handling of backgrounded tabs, so a meeting that looks fine on a laptop can feel cramped or behave differently on a handset. The Jitsi handbook directs React applications to the Jitsi React SDK, so confirm which integration path your front-end team has chosen before you plan mobile tests. Treat the mobile browser as a separate test target with its own results.
Certificates are the mobile problem most likely to block a meeting outright. The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. A desktop user can sometimes click through a browser warning. A phone may refuse the connection, withhold camera and microphone access, or fail inside the embedded frame without a clear message. Before any browser or app test, confirm that the certificate for the Jitsi domain is trusted on current iOS and Android versions, that the intermediate chain is served correctly, and that the portal page itself loads over HTTPS. Ask your security team who owns renewal, because an expired certificate is easy to miss until a user reports it.
Some users will want to join in the Jitsi Meet mobile app instead of the browser. The Jitsi handbook documents how to open a meeting on a custom server in the app: an org.jitsi.meet URL scheme on iOS and an Android intent URL. Your portal builds these links, so the team's domain and room name must be correct in both, or the app may open the wrong server or no meeting at all. Keep link generation in one tested function so the iOS and Android branches share the same domain and room naming. Check the exact link syntax against the handbook for the release you run, because the app's link format is the detail most likely to change between versions.
Test each platform on its own, with the app installed and with it absent. On iOS, confirm that the scheme opens the Jitsi Meet app, that the app connects to your server with no join through the public meet.jit.si service, and that a user without the app lands on a usable browser page. On Android, run the intent on the Android versions and browsers your users carry, confirm the app is selected and joins your domain, and test the fallback when the app is not installed. On both platforms, check camera, microphone and screen-sharing permissions, guest and authenticated joins, and whether the room name carries through correctly. Record the app version and server version used in each test, and ask the team that runs your Jitsi deployment which app releases it supports.
Why the embed fails and how to fix it
This table lists six failures that appear when a self-hosted Jitsi Meet is embedded with the IFrame API, with the symptom a user or administrator sees, the most likely cause and the fix to try first. Read each row from left to right, then check the cause against your domain, certificate, token and firewall settings. Confirm exact error messages and option names in the Jitsi handbook for your installed release, because they can change between builds.
| Failure | Symptom | Likely cause | Fix |
|---|---|---|---|
| Script does not load from external_api.js | The embed area stays blank, and the browser console reports that the script request failed | Wrong domain in the script URL, a certificate the portal's browsers do not trust, or the portal cannot reach the server on 443/TCP | Open https://your-domain/external_api.js directly from the portal's network, make sure the domain matches the certificate name, and allow 443/TCP from the portal's users and servers |
| Camera and microphone are blocked | The permission prompt never appears, or the devices stay off inside the frame | The page is served over plain HTTP, or the iframe lacks the allow attribute for camera, microphone or screen capture | Serve the portal and Jitsi over HTTPS, then set the iframe allow attribute to include the devices and screen sharing your version of the handbook documents |
| Room opens without moderator rights | Users who should host join as guests and cannot mute others or manage the lobby | The JWT is missing, expired or signed with a different secret, or its moderator claim, app ID or audience does not match the Prosody settings | Compare the issuer, audience, app ID and secret in the portal with the Prosody configuration, check token expiry and the moderator flag, and confirm the room in the token matches the room the embed opens |
| Guests are blocked or asked to sign in | Guests see an authentication prompt or cannot enter rooms that the signed-in users can open | The anonymous domain is not configured, so guest sessions have no domain to join through | Configure the anonymous domain as the handbook describes for JWT authentication, then test a guest join from a private browser window |
| Mobile users fail on certificates | Desktop browsers work, but phones and tablets show certificate errors or fail to connect | A self-signed or private certificate authority that mobile devices do not trust, a problem the handbook warns about for mobile clients | Replace the certificate with one from a publicly trusted authority, or distribute your certificate authority to managed devices, then test on current iOS and Android browsers |
| Media fails after joining | Users reach the room, but audio and video stay dark or drop on some networks | 10000/UDP is closed or blocked by a firewall, security group or NAT, so media cannot reach the videobridge | Open 10000/UDP to the videobridge and check cloud security groups, then review the optional 5349/TCP fallback and 3478/UDP STUN settings the quick start lists |
Questions to answer before embedding Jitsi Meet
What drives the cost of embedding a self-hosted Jitsi Meet?
The cost follows five drivers: the portal stack, the identity model, the number of meeting types, mobile handoff and the testing scope. A portal built on one framework with one sign-in source is a smaller job than several front ends that each need their own room rules and login flow. Build work is mostly one-time. Hosting, certificate renewal, Jitsi upgrades and post-launch support recur. Ask any quote to price each driver separately, mark which items are one-time and which recur, and state who owns the servers, certificates and test accounts. An itemized quote also shows what a narrower first release would save, so you can decide which meeting types and devices belong in the first phase.
Can our own team embed Jitsi Meet without a partner?
Yes, if your team already has the skills the work needs. The embed itself is front-end work with the IFrame API, but the Jitsi server underneath is a separate job. You need Linux operations, certificate management and front-end skills, plus someone who can maintain the deployment after go-live. The Jitsi scalable setup guide warns that building scalable infrastructure is not a task for beginning administrators and recommends configuration management tools such as Ansible or Puppet. Check your team against that list honestly. If one skill is missing, a partner can cover it under a written scope while your staff learn the system, and the handover should include runbooks and the upgrade steps.
How long does it take to embed Jitsi Meet in our portal?
The timeline depends on scope, so no single duration applies to every embed. The drivers are the same as the cost drivers: how many portal pages embed a meeting, how many identity sources sign users in, whether guests join through an anonymous domain, how much mobile testing is needed and whether the server is new or already running. Work on a server you already operate is shorter than work that also needs provisioning, DNS and certificates. Do not accept a duration that is not written down. Ask for a plan with phases, the client tasks each phase depends on, the test exit criteria and the handover date for each deliverable.
What do we need to provide before the embed work starts?
Have these ready before the first sprint: a domain you control for the Jitsi server, a valid certificate for that domain, an identity source, access to the portal code and environment, and named test users. The Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. Your identity source decides the authentication mode, whether internal XMPP accounts, JWT tokens, LDAP or Matrix user verification. Test users should cover moderators, guests, mobile users and each browser your staff use. Missing items usually cause delays, so confirm them in the written plan.
Should we use the IFrame API or the React SDK for Jitsi?
Use the IFrame API for most portals, and choose the React SDK when your front end is a React application and you want Jitsi to work as a component inside it. On a self-hosted deployment the IFrame API loads from your own domain at external_api.js and is created with a JitsiMeetExternalAPI object that takes the domain and options. The Jitsi handbook says it works on mobile browsers the same way as on desktop, and it points React applications to the React SDK. The server work is the same for both, so the choice mainly changes front-end code, component structure and the testing you plan for the portal.
What changes when we host our own server instead of meet.jit.si?
Your team becomes responsible for everything the public meet.jit.si service handles for you: the domain, certificate, open ports, updates, capacity and authentication. The IFrame API call points at your domain, so the script loads from your server and the room names, options and sign-in flow are yours to set. You also decide whether guests can join without an account, which usually means a separate anonymous domain for guests and token-based login for moderators. The handbook marks the older secure domain method, which uses a username and password for room creation, as deprecated for new installations and recommends JWT token authentication. Confirm each choice with the team that owns identity before the build starts.
Does the Jitsi embed work on phones and tablets too?
Mobile browsers run the IFrame API the same way as desktop browsers, but mobile use adds certificate and app handoff requirements. Meetings on a custom server can be opened in the Jitsi Meet mobile app with the org.jitsi.meet URL scheme on iOS and an Android intent URL. Your portal must generate the correct link for each platform, and users must have the app installed. Because self-signed certificates cause problems with mobile clients, a certificate trusted by the devices is required. Test on the phones and tablets your users carry, including the handoff from a portal page into the app. Ask for the mobile test cases in the written scope so the handoff is covered before go-live.
How DeployOpen scopes and delivers a Jitsi Meet embed
DeployOpen plans and delivers the embed as part of a self-hosted Jitsi Meet deployment in infrastructure you control, so the portal integration, the server settings and the domain certificate are designed together. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm which portal or application pages will host the embed and which users join meetings there.
- Record the domain, HTTPS certificate plan and whether guests join through a separate anonymous domain.
- Agree in writing whether room creation stays open or requires authenticated tokens for the embed.
How we build
- Configure the self-hosted deployment so external_api.js loads from your own domain over HTTPS.
- Write the JitsiMeetExternalAPI integration with options for room name, display name and interface settings.
- Test embed behavior on desktop and mobile browsers, including the org.jitsi.meet and Android intent links.
How we hand over
- Deliver the integration code, configuration files and a record of every setting that differs from the defaults.
- Document how the embed behaves compared with meet.jit.si, including features your deployment must enable itself.
- Walk your engineers through the upgrade impact on the embed so future Jitsi releases do not break the page.
How we support
- Offer ongoing support, upgrades and continuous testing for the embed as a retainer, scoped in writing.
- Check the embed after each Jitsi Meet update, since the IFrame API surface can change between releases.
- Agree a named contact and response process in the retainer before any production traffic depends on the embed.
