Blocked Requests

🛑 Handling Blocked Requests

To prevent losing responses when requests are blocked (e.g., by ad blockers or browser settings), the Quality Tools wrapper detects these blocked requests. It then assigns a default low score and marks the participant with a generic participantId of Request-Blocked.

• This helps maintain data integrity when external factors block requests.
• It prevents the loss of responses by assigning a default score.
• Ensures that blocked requests do not interfere with overall scoring and analytics.

If a request is blocked, the Quality Tools will:

• Assign Request-Blocked to string attributes.
• Return a device score of 0 for all device numeric metrics.
• Return false for the isDuplicate property.
• Return No Data for survey history metrics (e.g., manualISQRate) and lastSurveyTaken.
• Return 0 for quality checks (e.g., brandFamiliarity).
• Return NONE for the persona attribute. See Personas.

Response Example

{
  "requestId": "Request-Blocked",
  "participantId": "Request-Blocked",
  "dataTrustScore": 0,
  "persona": "NONE",
  "deviceScore": 0,
  "country": "Request-Blocked",
  "subdivision": "Request-Blocked",
  "lastSurveyTaken": "No data",
  "isDuplicate": false,
  "surveyId": "Request-Blocked",
  "averageDeviceScore": 0,
  "lowestDeviceScore": 0,
  "totalSurveys": 0,
  "deviceFailures": [
    "Request-Blocked"
  ],
  "completionRate": "No data",
  "duplicationRate": "No data",
  "failureRate": "No data",
  "qualificationRate": "No data",
  "manualISQRate": "No data",
  "automatedISQRate": "No data",
  "osqRate": "No data",
  "brandFamiliarity": 0,
  "openEnd": 0,
  "speeding": 0,
  "honeyPot": 0,
  "straightlining": 0,
  "distinctSupplierCount": 0,
  "suppliers": []
}

---

🌐 Browser Integration Requirements

Most Request-Blocked errors come from one of two browser-level policies — CORS or CSP. Both apply only to browser-based requests; server-to-server calls (Node, Python, Postman, cURL, etc.) are unaffected.

CORS & Local Development

If you're testing the integration from a browser-based environment (e.g. localhost or your own domain), the browser enforces Cross-Origin Resource Sharing (CORS) policies on the requests our Quality Tools make to api.dqco-op.com and fpmetrics.dqco-op.com.

You do not need to configure anything on your end. Our API already returns the necessary CORS headers to allow requests from browser environments.

If you are seeing a CORS error in the console, check the following:

• You are using the correct API key in the Authorization: apikey {API_KEY} header.
• Your request includes Content-Type: application/json.
• You are loading the page from http://localhost (or https://...) — not file://.

CORS only applies to browser-based requests. Server-to-server calls are not affected and will work without any additional configuration.

Environment	CORS applies?
Browser (localhost, your domain)	✅ Yes
Postman / cURL	❌ No
Server-to-server (Node, Python, Go, …)	❌ No

Content Security Policy (CSP)

If your website enforces a Content Security Policy, you need to whitelist the Quality Tools domains in your script-src (and any other relevant directive) — otherwise the browser will block the toolbox from loading and you will see Request-Blocked errors in the console.

Add one of the following to your CSP header:

Option A — Specific domains (more restrictive):

script-src https://api.dqco-op.com https://fpmetrics.dqco-op.com;

Option B — Wildcard subdomain (easier to maintain, recommended):

script-src https://*.dqco-op.com;

Without one of these, the Quality Tools toolbox will not load and you'll see Request-Blocked for every participant.

This only applies if your site has an active CSP policy. Most development environments do not enforce CSP by default — you'll typically hit this on staging or production.