Installing under a strict CSP
A site that sends its own Content-Security-Policy needs two directives for the widget, not five, and degrades safely if the frame is blocked.
If your site sends a Content-Security-Policy header, the browser blocks anything the policy does not name — including the widget. Two directives are enough to allow it.
Two directives
The snippet you paste is unchanged, but the script it loads is a small loader. The loader frames a same-origin shell served from your Evoriqa domain (or your provider's branded domain), and the widget runs inside that shell. Everything the widget does — its scripts, its API calls, its styles, and the in-chat booking frame — runs under our policy, inside the frame, not under your page's.
So your policy only has to allow our origin in two places:
script-src <origin>
frame-src <origin>The chatbot's Install tab prints those two lines with your actual origin filled in. Copy them from there rather than typing them.
Finding your origin
<origin> is the host in your snippet's <script src>: your provider's branded domain if you were set up on one, otherwise the Evoriqa app origin. It is the same value in both directives.
If your policy blocks the frame
Nothing breaks silently. When the host policy refuses the shell frame, the loader falls back to mounting the widget directly in the page, so visitors still get a working widget, and the block is reported back and shown as a banner on that chatbot's Install tab.
Treat the banner as a to-do rather than an outage: the fallback runs the widget under your page's policy, which is what the shell exists to avoid.
Where to go next
Last updated