Installing the widget
The Vectorspace widget is a single <script> tag. There is nothing to install on your server, no SDK to import, no package to add to your build. It works on any website or web application — WordPress, .NET, Rails, Next.js, plain HTML, anything that renders a page in a browser.
What you give us
Section titled “What you give us”Before we hand over the snippet, we need from you:
- The production domain(s) where the widget will run (e.g.
app.yourcompany.com). We allowlist these on our side — if a domain is not on the list, the widget refuses to load. This is a security feature, not a billing one. - The staging or homologation domain, if you have one and want to test there before going live.
That’s it. No DNS changes, no certificates, no firewall rules.
What we give you
Section titled “What we give you”A single line of code, customized for your project:
<script src="https://widget.vectorspace.digital/widget/{your-project}.js" async></script>The exact URL is unique to your project. You will receive it from us once your knowledge base is ready.
Where to put it
Section titled “Where to put it”Paste the snippet into the HTML of any page where the widget should appear. The most common pattern is the shared layout file — the template that renders on every page — so the widget is available site-wide.
Common locations by stack:
| Stack | File |
|---|---|
| .NET / ASP.NET Core | Views/Shared/_Layout.cshtml |
| Rails | app/views/layouts/application.html.erb |
| WordPress | header.php of your theme (before </head>) |
| Next.js | app/layout.tsx (in the <body>) or _document.tsx |
| Plain HTML | The <head> or just before </body> |
| Astro | A shared layout component, or head config |
Either inside <head> or just before </body> is fine. The async attribute means it never blocks page rendering.
Restricting to specific pages
Section titled “Restricting to specific pages”You don’t have to put the widget everywhere. If you only want it on, say, the help center or the registration flow, just include the snippet on those pages. Many customers do exactly this.
Security
Section titled “Security”The widget runs inside a sandboxed iframe, isolated from the host page. It cannot:
- Read your DOM, forms, or input fields
- Read or write your cookies
- Access user authentication state
- Execute code in your page’s context
The host page and the widget communicate only through a narrow, validated message channel that we control.
If you have a strict Content-Security-Policy, you may need to allow our widget origin in script-src and frame-src. We will give you the exact CSP directives when we send the snippet — they are short and specific.
After installation
Section titled “After installation”Once the snippet is live, the widget appears as a floating chat button (you can choose the corner and color during onboarding). Open a page, click the bubble, ask a question — that’s the full test.
If something looks wrong (button not appearing, wrong color, allowed-origin error in the console), send us a screenshot or the URL and we’ll fix it on our side. You do not need to redeploy to change the widget’s behavior, prompt, or styling — those live on our servers and update without touching your site.
Working with an external development team
Section titled “Working with an external development team”If the website where the widget will be installed is maintained by a third party (an agency, an internal IT team, a SaaS vendor), the cleanest path is:
- Forward them this page.
- Give them the snippet we provided you.
- Tell them which domain(s) the widget will run on, so we can allowlist them.
There is no need to give us repository access or run code on your side. The change on their end is one line in one file.