Consent-gated boot and self-hosting

Loading after consent (everyone installs)

If every visitor can open the widget, the plain script tag downloads widget.js from debuggo.dev on every page load. Whether that download needs consent depends on where your visitors are. Where it does, the only pattern that removes the pre-consent request is to insert the script tag itself after consent. Initialising later is not enough, because the download has already happened.

Strict: insert the script after consent

Define one function and call it from your consent tool. The widget initialises itself when the tag appears.

<script>
  // Call this from your consent tool's callback. Safe to call more than once.
  function loadDebugGo() {
    if (document.querySelector('script[data-key="YOUR_API_KEY"]')) return;
    var s = document.createElement("script");
    s.src = "https://debuggo.dev/widget/v1/widget.js";
    s.setAttribute("data-key", "YOUR_API_KEY");
    s.setAttribute("data-position", "bottom-right");
    s.setAttribute("data-color", "#3B82F6");
    s.defer = true;
    document.head.appendChild(s);
  }
</script>

Lighter: initialise after consent

If a script download before consent is acceptable where you operate, you can keep the tag in your HTML with data-auto-init="false" and start it yourself. Until you do, the script runs nothing: no button, no capture, no storage read.

<script
  src="https://debuggo.dev/widget/v1/widget.js"
  data-key="YOUR_API_KEY"
  data-auto-init="false"
  defer
></script>
<script>
  // The script is on the page but does nothing until this runs.
  function startDebugGo() {
    if (window.__debuggoStarted) return;
    var boot = function () {
      window.__debuggoStarted = true;
      new window.DebugGoWidget({
        apiKey: "YOUR_API_KEY",
        position: "bottom-right",
        color: "#3B82F6"
      });
    };
    if (window.DebugGoWidget) boot();
    else document.querySelector('script[data-key="YOUR_API_KEY"]')
      .addEventListener("load", boot);
  }
</script>

Consent tool callbacks

Examples for Cookiebot, OneTrust, Usercentrics and Klaro. Each one calls the loadDebugGo() function from the strict pattern above; swap in startDebugGo() for the lighter one. Put DebugGo in your tool's functional or preferences category, not in marketing: it does no advertising and no cross-site tracking.

<script>
  // Cookiebot fires this on accept and again on later page loads
  // where consent already exists.
  window.addEventListener("CookiebotOnAccept", function () {
    if (window.Cookiebot && Cookiebot.consent.preferences) loadDebugGo();
  });
</script>

<script>
  // OneTrust calls OptanonWrapper on load and after every consent change.
  // C0003 is the "Functional Cookies" group; use the id of the group you
  // placed DebugGo in.
  function OptanonWrapper() {
    if ((window.OnetrustActiveGroups || "").indexOf("C0003") !== -1) {
      loadDebugGo();
    }
  }
</script>

<script>
  // Add a service named "DebugGo" in the Usercentrics admin and enable the
  // "window event" integration with the event name "ucEvent".
  window.addEventListener("ucEvent", function (e) {
    if (e.detail && e.detail.event === "consent_status" && e.detail["DebugGo"] === true) {
      loadDebugGo();
    }
  });
</script>

<script>
  var klaroConfig = {
    services: [
      {
        name: "debuggo",
        title: "DebugGo feedback widget",
        purposes: ["functional"],
        callback: function (consent) {
          if (consent) loadDebugGo();
        }
      }
    ]
  };
</script>

Self-hosting the widget

Serving the widget from your own domain removes the only request an ordinary visitor would otherwise make to DebugGo. Submissions still go to DebugGo when someone presses Send, and review links still call the review API, but nothing leaves the page before that.

1. Copy the four files

# Copy all four files into the same directory on your origin.
# review.js, capture.js and capture-source.js are resolved relative to widget.js.
curl -O https://debuggo.dev/widget/v1/widget.js
curl -O https://debuggo.dev/widget/v1/review.js
curl -O https://debuggo.dev/widget/v1/capture.js
curl -O https://debuggo.dev/widget/v1/capture-source.js

2. Point the tag at your copy

data-app-origin tells the widget where the review API lives. Only https://debuggo.dev is accepted as an override; any other value falls back to the script's own origin.

<script
  src="https://www.example.com/vendor/debuggo/widget.js"
  data-key="YOUR_API_KEY"
  data-app-origin="https://debuggo.dev"
></script>

3. Keep it current

A self-hosted copy does not update itself. Re-copy the four files when the changelog announces a widget release; mixing versions between the files breaks the review layer.

Content Security Policy

With self-hosting, your script-src no longer needs debuggo.dev. Submissions and review calls still need connect-src entries for the API and the submission endpoint:

Content-Security-Policy:
  script-src 'self';
  connect-src 'self' https://debuggo.dev https://ezkzeffhjuequduibozr.supabase.co;

Comparison