← Integration Guides

Option 2 — Browser + Proxy Guide

Use this pattern when JavaScript on your public page should validate a phone number or email before or without a full page submit, while keeping the server-side API key only on the server (proxy) you control (never use a client-side API key in your proxy).

What you need

• An active Data Checks account, credits for the service you call, and a server-side API key.
• HTTPS on the pages your visitors use (recommended for any form or API traffic).
• One or two HTTP routes on your stack that accept JSON and call https://api.data-checks.com/v1/email and/or https://api.data-checks.com/v1/phone.
• If you enable allowed IPs on that API key, include the IP of the machine that calls Data Checks (your proxy host), not visitors’ IPs.

Minimal browser example

Call your own path; adjust URL and CSRF token to match your site.

async function validateEmail(email) {
  const res = await fetch('/api/validate-email', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Accept': 'application/json',
      // 'X-CSRF-TOKEN': document.querySelector('meta[name="csrf-token"]').content,
    },
    body: JSON.stringify({ email }),
  });
  const data = await res.json().catch(() => ({}));
  if (!res.ok) throw new Error(data.message || data.error || ('HTTP ' + res.status));
  return data;
}

The same snippet is in the starter packs as examples/browser-validate-email.js along with examples/browser-validate-phone.js.

Starter downloads

Download example implementations. Unpack a ZIP on your machine, set DATA_CHECKS_API_KEY to a server-side key value, and follow the README.

Security checklist (do this on your proxy)

• Never put a server-side API key in client-side code, HTML, or public repos. Use an environment variable or secrets manager for server-side keys.
• Validate and bound input length (email and phone strings should match the limits in the API Specs).
• Apply your own rate limiting per session or IP on the proxy route so a single browser cannot burn credits.
• For same-site forms, use your framework’s CSRF protection on POST routes. For cross-origin SPA calls, prefer tight CORS and/or authenticated sessions instead of a wide-open public proxy.
• Consider stripping remaining_credits from JSON returned to the browser so account usage is not visible to visitors.
• Log without storing raw personally identifiable information (PII) unless your retention policy allows it.

CORS

If your JavaScript runs on the same origin as the proxy (typical for a first-party site), you do not need CORS headers for that call.

If the browser calls your API from another subdomain or domain, configure CORS on your proxy to allow only the origins you trust, and keep preflight rules narrow.

Rate limits

The Data Checks API is rate-limited at 60 requests per minute. See the API Specs for details. Map 429 responses to a friendly message and backoff.

Troubleshooting

• 4xx API errors — see the PDF references on the API Specs page.
• CORS errors in the browser — fix headers on your proxy, not on the Data Checks API (the browser should not call Data Checks directly for this pattern).

Support boundaries

Data Checks supports the behaviour of the public API and your account. Custom proxy code runs on your infrastructure: you maintain TLS, logging, auth, and abuse controls. Requests are checked against your key type (server-side optional IP allowlist; client-side required allowed domains). If a request reaches our API with a valid key and fails with our documented status codes, use this guide and the API Specs; if the problem persists, contact support with timestamps and the HTTP status, without full personally identifiable information (PII).