Install guide
Installing a chat widget on a Framer site
Framer's install is one paste into a site settings field, and then one thing you have to remember: publishing is what ships it. The canvas will never show you the result, so the whole verification loop happens on the published address.
The tag
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>Your own key replaces the placeholder. You will find it on the install tab of the assistant.
The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
Where it goes on Framer
Site settings, then the custom code section, then the field for the end of the body tag.
Framer puts published custom code behind a paid site plan. Confirm the custom code fields are usable on your plan before you build a process around them, because the canvas gives you no signal either way.
Step by step
- 1Open the project, then site settings, then the custom code section.
- 2Choose the field for the end of the body tag rather than the head field.
- 3Paste the tag and replace the placeholder with your own key.
- 4Publish the site. Framer holds custom code until a publish runs, so nothing is live before that.
- 5Open the published address rather than the canvas, and confirm the launcher appears.
- 6Allowlist the staging address as well as your domain if you plan to check anything before a domain is connected.
What goes wrong on Framer
Nothing runs on the canvas
Custom code is applied when Framer builds the published site, so the editing canvas never executes it. There is no toggle that changes this and no error to read.
Verify on the published address only. Anything you conclude from the canvas about whether the tag works is guesswork.
The Framer staging address is not your domain
A Framer project is reachable at a framer.app or framer.website address as well as at any custom domain you connected, and a browser sees those as different origins. Allowlist only the domain and every staging check comes back empty with the refused origin named in the console.
Apex and www are also separate, so decide which one visitors actually land on and cover both.
The field saves instantly, the site does not
Editing the custom code field takes effect the moment you type it, in the project. The published site keeps serving the previous build until a publish runs, and Framer's publish action does not distinguish a code-only change from a design change.
On a shared project this produces a strange failure: your tag goes live hours later, in somebody else's publish, alongside design changes you never reviewed.
Origins to allowlist
These are the origins a Framer site is typically served from. List every one you want the assistant to answer on, including the ones only you visit.
- https://your-site.framer.website
- https://yourdomain.com
- https://www.yourdomain.com
How the tag behaves, wherever you put it
The rest of this is the same on every platform, so it is worth reading once rather than on each guide.
| One tag, nothing else | There is no second file, no stylesheet and no package to install. The tag is the whole install. |
|---|---|
| Where it goes | Immediately before the closing body tag. It works in the head too, because it defers, but the body keeps it out of the way of anything that measures render order. |
| data-key is required | Without it the loader stops and writes a warning to the browser console rather than rendering anything. |
| It finds itself | The loader reads the tag it was loaded from, and falls back to the first tag on the page carrying a data-key. Platforms that move or re-inject the tag do not break it. |
| It installs once | A second copy of the tag on the same page is ignored, so a template that renders twice does not produce two launchers. |
| Assets follow the tag | Everything else it needs is fetched from the same origin the tag was served from, so a proxy or a private domain needs no extra configuration. |
| The panel loads late | Only the small launcher is on the page at first. The conversation panel is fetched the first time a visitor opens it, in its own frame. |
| Styles cannot collide | The launcher renders inside a closed shadow root and the panel inside a frame, so nothing on the host page can restyle either, and neither can restyle the host page. |
Set up on Framer for a particular trade
The tag is the same everywhere. What is not the same is which of your pages the assistant can read once it is running, and on Framer that depends on what kind of site this is. These go one level further than this guide.
- For a marketing agencyAgencies run their own project and a dozen client projects from the same code field. One key across all of them mixes clients' material.
- For a fintech appThe number sits in one element and the sentence that qualifies it in another, and publishing a financial promotion here is one button anyone with access holds.
Taking it off again
Clear the end of body field in site settings and publish again. The published build carries the tag until that publish replaces it.
Before you remove it
- Removing the tag stops the widget on that site. It does not delete the assistant, its material, or the enquiries it has already collected.
- If you are moving the widget to a different host rather than retiring it, add the new origin to the allowlist before you remove the old tag, or there is a window where neither works.
Questions
- Head field or end of body field?
- End of body. The tag defers, so it would not block rendering from the head either, but keeping third-party markup out of the head means one less thing to rule out when something else on the site misbehaves.
- Does it survive Framer's page transitions?
- Yes. The loader installs once per document load and refuses to install a second time, so moving around the site does not stack up copies and does not tear the launcher down.
- Can it answer from a Framer CMS collection?
- Yes, for published items. A crawl of your site follows your own links and reads a published collection page the way a visitor would. Drafts are not served publicly, so they are not read.
- Will it interfere with my Framer animations?
- No. The launcher lives in a closed shadow root and the panel is a separate frame, so your styles and effects do not reach into it and nothing it renders can leak into your layout.
Keep reading
- Install on WebflowProject settings, then the Custom code section, then the field for code before the closing body tag.
- Install on SquarespaceSettings, then Advanced, then Code Injection, then the Footer field.
- Install on WixSettings, then Custom Code, then a new snippet applied to all pages and placed at Body end.
- Every install guideThe same one line of HTML, and where it goes on each platform.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.