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.

A 403 is not a CORS problem

If the console shows a 403 from api.dqco-op.com rather than a CORS error, the key is being used where it is not allowed: a private key from a browser, a public key on GET /tools/request, or a site that is not in the key's allowed domains. The messages and the fix for each are on Key types, under public key errors, allowed domains errors and private key errors.

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.