iFrame and Web Components

Overview

There are two ways to put a Veeting meeting into your own application: 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.

Both are driven at runtime by 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 an empty 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 it 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 participants would 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 denies the meeting room access to the camera and microphone, and the participant joins with no media and no useful error. Copy the list above exactly.

Add query parameters to the src URL to preset 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 answer.
  2. The page is served over HTTP. The meeting room allows framing only from HTTPS origins.
  3. The allow attribute is missing or incomplete, so the room loads but the participant has no camera or microphone.
  4. A Content-Security-Policy on your own page blocks the frame. Check frame-src in your policy, not ours.

Web components

Alongside Veeting Blocks, there are a few standalone web components: custom HTML tags that embed one piece of meeting functionality 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 component set we are actively 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

Attributes configure the element. The example here uses the Coffee Table component:

AttributeDescription
api-hostThe hostname of your meeting room instance, for example https://rooms.veeting.com.
participant-nameThe name shown to others in the meeting. Use Anonymous if you do not know it.
meeting-idThe meeting the component connects to. Use the dashed meeting number.
css-urlOptional. A URL to an external stylesheet, so you can restyle the 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 scripts. 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 that it always matches your platform version.

<!-- 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>

Common mistakes

  • Embedding an iFrame before allowIFrameEmbedding is enabled, then reading the empty 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.
  • Starting new work on the standalone components rather than Veeting Blocks.

Not sure how to best implement your project?

Contact our team to discuss the details.