Request failed with status code 400

Description

Unable to save cookie data, we keep getting the error “Request failed with status code 400”

We have relaunched the app, we have refreshed the page, we have cleared browser cache and cookies, no luck

Site URL

Required: Please provide a staging/production URL where we can see the issue

Steps to Reproduce

  1. Scan site
  2. Edit auto detected cookies
  3. click save

Video/Screenshots

Required: Please provide a short screen recording showing the issue

{
“success”: false,
“error”: “Invalid query parameters”,
“details”: [
{
“expected”: “string”,
“code”: “invalid_type”,
“path”: [
“siteId”
],
“message”: “siteId query parameter is required for this operation”
}
]
}

NDA Notice: If you’re under an NDA, please feel free to send us a Direct Message/Email with the above information.

Hey @kparsley!

That error is coming directly from the Consent Pro dashboard API:

{
  "error": "Invalid query parameters",
  "details": [{ "message": "siteId query parameter is required for this operation" }]
}

The siteId parameter is something the dashboard frontend should be sending automatically when saving a tracker — this isn’t something you’d configure manually. Based on similar cases we’ve seen, this pattern points to a dashboard-side issue rather than anything in your setup. :thinking:

A few quick things worth trying while we loop in the team:

  1. Hard refresh the dashboard (Ctrl+Shift+R or Cmd+Shift+R) to make sure you’re on the latest app version
  2. Try in a different browser or incognito window to rule out session or extension interference
  3. Re-enter the site from the main workspace rather than navigating directly to the tracker editor

If those don’t resolve it (which is likely given you’ve already cleared cache and cookies), the team will need to dig into the dashboard-side request directly.

One separate thing worth flagging — your live site is currently running the older v1 cookie consent script (@finsweet/cookie-consent@1/fs-cc.js) with fs-cc attributes, while you’re using the Consent Pro v2 dashboard. This is unrelated to the 400 error, but once the dashboard issue is sorted, you’ll want to migrate the on-site script to v2 as well. Happy to walk you through that when you’re ready.

We’re looping in the team now to investigate the save-tracker API issue — they’ll have the full context to dig in. :flexed_biceps:

Hey @kparsley

To add on to what @Support-Finn said, you could also try reauthorize the app or do a full sign-out/sign-in of your Webflow account

Other than that, the site is currently running two consent systems at once, there’s both the consentpro v2 & the legacy v1
Site visitors could probably be interacting with the legacy banner, not ConsentPro’s, and ConsentPro’s dashboard may not have a real “live” banner component tied to this site to manage
This could potentially be contributing to why edits/saves in the dashboard are behaving strangely

In the section
Remove the legacy cdn & the IIFE next to it

<script defer src="https://cdn.jsdelivr.net/npm/@finsweet/cookie-consent@1/fs-cc.js" fs-cc-mode="opt-in"></script>
<script>
  (function () {
    function checkAndSync(input) {
      if (!input) return;
      input.checked = true;
      input.setAttribute('checked', '');
      input.dispatchEvent(new Event('input', { bubbles: true }));
      input.dispatchEvent(new Event('change', { bubbles: true }));
      input.classList.add('w--redirected-checked');
    }

    function setConsentDefaults() {
      checkAndSync(document.querySelector('input[fs-cc-checkbox="marketing"]'));
      checkAndSync(document.querySelector('input[fs-cc-checkbox="analytics"]'));
    }

    function isVisible(el) {
      const s = getComputedStyle(el);
      return s.display !== 'none' && s.visibility !== 'hidden' && parseFloat(s.opacity) > 0;
    }

    function attachModalObserver(modal) {
      if (isVisible(modal)) setConsentDefaults();
      new MutationObserver(() => {
        if (isVisible(modal)) setTimeout(setConsentDefaults, 50);
      }).observe(modal, { attributes: true, attributeFilter: ['style', 'class'] });
    }

    function isCategoryAllowed(category) {
      try {
        var match = document.cookie.split('; ').find(function (row) {
          return row.startsWith('fs-cc=');
        });
        if (!match) return false;
        var data = JSON.parse(decodeURIComponent(match.split('=').slice(1).join('=')));
        return data[category] === true;
      } catch (e) {
        return false;
      }
    }

    function syncToWebflow(analyticsAllowed) {
      wf = window.wf || (window.wf = []);
      wf.ready =
        wf.ready ||
        function (cb) {
          (wf._ready = wf._ready || []).push(cb);
        };
      wf.ready(function () {
        if (analyticsAllowed) {
          wf.allowUserTracking({ activate: true });
        } else {
          wf.denyUserTracking();
        }
      });
    }

    document.addEventListener('DOMContentLoaded', function () {
      const modal = document.querySelector('.modal.preferences-modal');
      if (modal) attachModalObserver(modal);
      syncToWebflow(isCategoryAllowed('analytics'));
    });

    document.addEventListener('fs-cc-analytics-activated', function () {
      syncToWebflow(true);
    });

    document.addEventListener('fs-cc-analytics-deactivated', function () {
      syncToWebflow(false);
    });
  })();
</script>

In the footer section Before </body>
Remove section

  let cookieName2 = 'cookiesClosed';
  if(typeof Cookies.get(cookieName2) !== 'undefined') {
    $('.cookie-consent-banner').remove();
  }
  $('.cookie-banner-close').on('click', function() {
    Cookies.set(cookieName2, 'ok', { expires: 1 });
  })
  $('#deny-cookies').on('click', function() {
    Cookies.set(cookieName2, 'ok', { expires: 1 });
  })
  $('#allow-cookies').on('click', function() {
    Cookies.set(cookieName2, 'ok', { expires: 365 });
  })

Then now remove the two components tied to the legacy v1 consent script
They have the classes cookie-consent-banner & cookie-consent-preferences

That should fully get rid of the legacy consent