Skip to main content
Most AntifraudAI integration issues fall into a small set of recurring categories. Work through the relevant accordion below to diagnose and resolve your issue. If the problem persists after following the steps here, open a support ticket from the dashboard and include the request_id from the API response — it lets our team trace the exact request.
A 401 response means AntifraudAI could not authenticate the request. Check the following in order:1. Confirm you’re using the right key prefix for the environment.
  • Sandbox requests require a key that starts with sk_test_.
  • Production requests require a key that starts with sk_live_.
  • Sending a sk_test_ key to https://api.antifraudai.com/v1 (or vice versa) will always return 401.
2. Verify the Authorization header format.The header must be exactly:
Common mistakes include:
  • Using Token or APIKey instead of Bearer.
  • Including quotes around the key: Bearer "sk_test_..." ❌
  • Leading or trailing whitespace in the key value.
3. Check that the key has not been revoked.Log in to the dashboard, navigate to Settings → API Keys, and confirm the key shows a Active status. If it was revoked, generate a new key and update your environment variable.
If a large proportion of events are returning block decisions, work through these checks:1. Check for reserved test user IDs in production. In the sandbox, sending user_id: "test_block" always returns a block decision. If this ID (or similar test fixtures) accidentally made it into a production data pipeline, every event for that user will be blocked.2. Review your custom rules. Navigate to Settings → Rules and look for recently created or modified rules. A rule that matches too broadly — for example, blocking all events from a particular country or device type — can silently block large volumes of legitimate traffic.3. Check your risk threshold settings. If the Review/Block boundary was recently lowered (e.g., from 70 to 30), far more events will be blocked. See Risk Thresholds for guidance on adjusting boundaries safely.4. Inspect the signals array. The response body includes a signals array that lists the factors driving the score. Identifying a common signal across blocked events (e.g., ip_reputation or velocity_anomaly) will point you toward the root cause.
Elevated scores on known-good users are most common in two scenarios:Early in your integration — AntifraudAI’s ML models rely on behavioral history to establish a baseline for each user. New users and new integrations naturally produce higher scores until sufficient history accumulates (typically 48–72 hours of real traffic).VPN and proxy usage — Legitimate users who route traffic through VPNs, corporate proxies, or Tor exit nodes will trigger the ip_reputation and anonymizing_proxy signals, raising their scores even if their behavior is benign. Consider adjusting thresholds or adding these users to a review list rather than blocking outright.Steps to investigate:
  1. Pull the event from the dashboard and review the Score Explanation panel.
  2. If the user is known-good, add them to the allowlist under Settings → Rules → Allowlist.
  3. If a specific signal is consistently over-weighted for your user base, contact support to discuss custom signal weighting available on the Enterprise plan.
If webhook events are not arriving at your endpoint, check the following:1. Confirm your endpoint returns a 2xx status code. AntifraudAI considers any non-2xx response a delivery failure and will retry with exponential backoff. Make sure your endpoint responds with 200 OK (even if processing is asynchronous) before timing out.2. Verify HTTPS is used. AntifraudAI only delivers webhooks to https:// endpoints. Plain http:// URLs will be rejected at save time.3. Check your firewall allows AntifraudAI’s IP ranges. Webhooks originate from a fixed set of IP addresses listed in Settings → Webhooks → Delivery IP Ranges. Add these IPs to your server’s allowlist if you have ingress filtering enabled.4. Check signature verification. If your endpoint verifies the X-AntifraudAI-Signature header and is rejecting requests, confirm you are:
  • Using the correct webhook secret (found in Settings → Webhooks).
  • Computing the HMAC over the raw request body, not a parsed/re-serialized version.
  • Comparing the full hex digest, not a truncated version.
5. Check delivery logs. The dashboard at Settings → Webhooks → Delivery Log shows every attempted delivery, the HTTP status your endpoint returned, and the full response body — this is the fastest way to identify the failure mode.
AntifraudAI’s typical end-to-end latency is under 100 ms at the 95th percentile. If you are observing higher latency, consider the following:Large metadata objects — The metadata field accepts arbitrary key-value pairs, but very large objects (tens of kilobytes) increase serialization and processing time. Trim metadata to the fields that are genuinely useful for scoring.Geographic distance — If your servers are far from AntifraudAI’s nearest region, network round-trip time will dominate. Enterprise customers can request region-pinned endpoints to minimize latency.Synchronous blocking in your application — If your application awaits the AntifraudAI response synchronously on the main request thread, even a 50 ms API call will be user-visible. For non-critical event types (e.g., login events where you don’t need the result in real time), consider an async pattern: send the event in a background job and act on the result via webhook.Connection reuse — Ensure your HTTP client reuses connections (keep-alive / connection pooling) rather than opening a new TCP connection for every request.
This is expected behavior. The sandbox and production environments use separate, independent ML models:
  • Sandbox is trained on synthetic data designed to exercise the full range of scores. It does not reflect real-world fraud patterns and is intentionally deterministic for common test inputs.
  • Production benefits from real-world event history across all AntifraudAI customers (in aggregate and anonymized), giving the model far richer context to evaluate any given event.
Use the sandbox to validate your integration logic — that your code correctly handles allow, review, and block decisions — not to predict what scores real users will receive.
Cases are only created for events that receive a review decision. allow and block decisions do not generate cases. Before searching the dashboard, confirm the event’s decision field from the API response or the Events log.If the decision was review and you still can’t find the case, check the Cases filter:
  • The default view shows Open cases only. Cases that have already been resolved (marked as fraud or legitimate by your team) are hidden by default.
  • Use the status filter dropdown to switch to All or Resolved to find closed cases.
  • If you are in a multi-member team, the case may be assigned to a specific team member and filtered from your view — remove the Assigned to me filter to see all cases.