The Web Calling widget puts your agent on your website. Visitors click the launcher, their browser connects over WebRTC, they're talking to your agent. You set it up under **Configure > Web Calling** in Agent Studio: name, domain, environment, branding, copy, embed. The rest of these pages cover the four things you'll actually do with the widget: Brand it, write the welcome line, set the agent voice and disclaimer. One script tag, paste before ``. Direct HTML or Tag Manager. Hosted preview link you can send to anyone, no login required. Microphone, network, cross-tab lock, and other call-quality issues. ## Before you start * The web domain(s) where you'll embed the widget. * Access to your site's HTML or your tag manager. * A published variant in **Sandbox** or **Live** for the agent that'll respond. * An **HTTPS** site. Browsers block microphone access on insecure origins.

PolyAI widgets put your agent on your website in minutes. From **Configure > Web Calling** in Agent Studio, create a widget, brand it, copy the script tag, and ship it. Phone and Chat widgets share the same editor: same styling controls, same content fields, same embed flow. The widget type just determines whether visitors get a voice call or a text conversation. ## Pick a widget type Click-to-call voice on your website. Visitors talk to your agent directly in the browser over WebRTC. No number to dial, no app to install. Text chat on your website. Visitors type to the same agent that answers your phone calls, with channel-specific styling and safety filters. You can run both on the same site. Many teams ship a Phone widget on high-intent pages and a Chat widget elsewhere. ## What's the same, what's different Everything in the editor (widget name, website URL, variant, environment, agent name, primary color, disclaimer, and policy URLs) works the same way for both types. Chat widgets add a few extra editor fields the call card doesn't need: * **Header text** and **header image** (logo). * **Agent avatar** shown next to messages. * **Consent button** ("I consent and start chat") before the conversation starts. * **Bubble prompt** style defaults (text and background color) for the speech bubble next to the launcher. Beyond the editor, runtime behavior differs by modality. Phone has microphone permission, mute, call states, and a cross-tab call lock. Chat has transcripts, suggestion chips, attachments, and richer launcher controls (auto-open, render mode, animation, iOS WebView). Both expose a global JavaScript API on the host page so you can drive them from your own code. For runtime and SDK detail, go to the product page: * [Web Calling](/polyphone/introduction): call states, mic permission, cross-tab lock, and the `PolyphoneAPI` reference. * [Webchat](/webchat/introduction): chat panel, suggestion chips, and the `WebchatAPI` reference. For Chat-specific script-tag attributes (`data-platform`, `data-render-mode`, `data-auto-open`, `data-show-icon`, `data-show-header`), see [Install on your site](/widgets/install#script-tag-attributes-chat-widgets). ## Prerequisites Before you create a widget you'll need: * The web domain(s) where you'll embed it. * Access to your website's HTML or your tag manager. * A published variant for the agent that will respond. * An **HTTPS** site. Required for Phone (microphone access), recommended for Chat. For **Chat** widgets, complete [Chat configuration](/webchat/chat-configuration) (LLM, greeting, safety filters) before creating the widget. ## Next steps Brand it, write the copy, set up consent. One script tag, live in minutes. Direct HTML or Tag Manager. Hosted preview link for stakeholder review (Phone widgets). Microphone, network, CSP, and rendering issues.