iFrame and Web Components

Overview

You can put a Veeting meeting into your own application in two ways: embed the whole meeting room in an iFrame, or place individual pieces of it on your page as components. This page covers both and helps you choose.

• An iFrame gives you the complete meeting room, including the join screen, in a few lines of HTML. It is the fastest route and the right default.
• Veeting Blocks gives you the individual components (video, chat, whiteboard, participants, and more) to arrange in your own layout. Use it when the meeting has to look like part of your product rather than a window inside it.

You drive both at runtime through the same JavaScript API.

Using this page with an AI assistant

If you are using an AI coding assistant, copy the text below into it and add a sentence describing what you want to build. AI assistants accessing this page receive a separate, token-optimized version of our full developer documentation, specifically tailored by our engineers for AI coding assistants.

Before writing any code, read this page:
https://www.veeting.com/en/developer-documentation/iframe-and-web-components

It documents how to embed Veeting Rooms. Keep these five rules in mind:

1. iFrame embedding must be enabled per instance. If the frame is
   blank, check for an X-Frame-Options response header before
   assuming the code is wrong.
2. The iFrame allow attribute is required, or there is no camera and
   no microphone. Copy it exactly from that page.
3. The embedding page must be served over HTTPS.
4. Use the dashed meeting number in a meeting URL or a meeting-id
   attribute, not the 24 character id.
5. Ask me whether I want the whole room in an iFrame or individual
   components. For components, prefer Veeting Blocks.

What I want to build:

Embedding the meeting room in an iFrame

First, get iFrame embedding enabled

iFrame embedding is off by default, which is why most first attempts show a blank frame. Every instance has a feature flag, allowIFrameEmbedding. While the flag is off, the meeting room responds with an X-Frame-Options: SAMEORIGIN header, and the browser refuses to display the room inside a page on any other domain.

Ask us or your reseller to enable the flag for your instance. It is a server-side setting, not something you can switch from your own page.

The markup

There is no special embedding URL. Use the normal meeting room URL, the same one your participants open directly:

<iframe src="https://<DOMAIN-NAME>/meeting/<MEETING-ID>"
  allow="microphone;camera;encrypted-media;fullscreen;autoplay;display-capture;layout-animations;">
</iframe>

The allow attribute is not optional. Without it, the browser blocks the meeting room from using the camera and microphone, and the participant joins with no media and no useful error message. Copy the list above exactly.

Add query parameters to the src URL to pre-fill the participant's name, skip the join screen, choose a layout, hide sections, and more. Anything you can configure from a URL works the same inside an iFrame.

When the frame stays blank

In order of likelihood:

1. allowIFrameEmbedding is off. Open the meeting room URL directly and look at the response headers. If X-Frame-Options: SAMEORIGIN is present, that is the cause.
2. Your embedding page is served over HTTP. The meeting room allows framing only from HTTPS origins.
3. A Content-Security-Policy on your own page blocks the frame. Check frame-src in your policy, not ours.

If the frame loads instead: when the participant has no camera or microphone, the allow attribute is missing or incomplete.

Web components

Alongside Veeting Blocks, there are a few standalone web components: custom HTML tags that embed one piece of the meeting without an iFrame and without a build step. You configure them entirely through HTML attributes.

Which should I use? For new work, prefer Veeting Blocks. It covers far more of the meeting room, is the set we are still developing, and has a full JavaScript API. The standalone components remain available for existing integrations.

A component is two things: an HTML element and a script that brings it to life. The script must come after the element.

The element

You configure the element through its attributes. The example here uses the Coffee Table component:

<coffee-table api-host="https://<DOMAIN-NAME>"
  participant-name="Joe Doe"
  meeting-id="3973-0113-4384-0768"
  css-url="https://<URL to an external CSS file, optional>"></coffee-table>

The scripts

You need two script files. The first is the official WebRTC adapter, which smooths over browser differences. The second is the component itself. Load it from your own meeting room instance so it always matches your platform version. The component stays empty until your page calls its join() method, so call it after the component script, as the last script below does.

<!-- WebRTC adapter, for browser compatibility -->
<script type="text/javascript"
  src="https://webrtc.github.io/adapter/adapter-latest.js">
</script>

<!-- the web component itself -->
<script type="text/javascript"
  src="https://<DOMAIN-NAME>/component/coffee-table/elements.js">
</script>

<!-- join the meeting; until then the component renders nothing -->
<script type="text/javascript">
  customElements.whenDefined("coffee-table").then(() => {
    document.querySelector("coffee-table").join();
  });
</script>

Common mistakes

• Embedding an iFrame before allowIFrameEmbedding is enabled, then reading the blank frame as a code problem.
• Leaving out the allow attribute, so the participant joins with no camera or microphone.
• Serving the embedding page over HTTP.
• Passing the 24-character meeting id to meeting-id, which expects the dashed number.
• Loading the component script from an instance other than the one in api-host.
• Putting the component script before the element it brings to life.
• Forgetting to call join(), so the component stays empty.
• Starting new work on the standalone components rather than Veeting Blocks.