AbuseZero

Monitor your integration

Watch results over time, trace requests, check browser protection and review changes to your workspace.

AbuseZero records every evaluation, every evaluation request, successful or failed, and every change to your workspace, and keeps watch over your browser protection setup. This guide shows where each of those lives, and ends with a scheduled check that alerts your team when something needs attention. Most of it is also in the dashboard, on the Analytics page and under Developers.

Before you begin

  • A server key with the scopes analytics:read, request_logs:read, audit_logs:read, browser_collection:read and outcomes:read.

Review evaluations over time

GET /v1/analytics returns one daily summary per day and result, for 1 to 90 days back. The default is 30. The AbuseZero CLI command is abusezero analytics get, and the AbuseZero MCP server tool is abusezero_get_analytics.

import { abusezero } from "./lib/abusezero";

const analytics = await abusezero.analytics(30);
Response (abridged)
{
  "object": "list",
  "data": [
    { "object": "daily_summary", "day": "2026-10-28", "result": "allow", "count": 1184 },
    { "object": "daily_summary", "day": "2026-10-28", "result": "deny", "count": 97 }
  ],
  "next_cursor": null
}

When the share of deny results changes suddenly, check what changed on your side first: a new policy, a new benefit setting, or the identifiers your code sends.

Trace a request

Every response carries an X-Request-ID header, and every error repeats it as request_id. Log it with every call your server makes, together with the error code when there is one. REST API errors explains each code.

Request logs list your workspace's evaluation requests, including failed ones with their HTTP status and error code. Each log's ID is req_ followed by the request's X-Request-ID, for REST and MCP requests alike, so you can match a log line in your system to its record in AbuseZero. Requests that never authenticated and rate-limited requests aren't logged. Read them with GET /v1/request-logs, abusezero request-logs list in the AbuseZero CLI, or abusezero_list_request_logs on the AbuseZero MCP server.

const logs = await abusezero.requestLogs({ limit: 50 });
Response (abridged)
{
  "object": "list",
  "data": [
    {
      "object": "request_log",
      "id": "req_1c2d3e4f-5a6b-4c7d-8e9f-0a1b2c3d4e5f",
      "status": 200,
      "code": null,
      "created_at": "2026-10-29T14:58:31.000Z"
    }
  ],
  "next_cursor": null
}

Check browser protection

Browser setup reports the one issue that most needs fixing, if any, and what recent evaluations received from the AbuseZero browser SDK over the last seven days. The AbuseZero CLI command is abusezero browser-collection get.

curl https://api.abusezero.com/v1/browser-collection \
  -H "Authorization: Bearer $ABUSEZERO_SECRET_KEY"
issueWhat to do
not_passed_onYour pages collect device tokens, but your server doesn't send them. Pass deviceToken through to identifiers.device_token.
site_not_listedA page outside your site list is sending browser data. Add its origin in Developers → Browser setup.
sdk_outdatedA site runs an outdated browser SDK. Update the package or the standalone script address.
script_missingAbuseZero hasn't seen the browser SDK on your sites. Check that it loads on every page where people claim a benefit. See Troubleshooting.

issue_since shows when the issue started. coverage counts each browser data status over the same seven days.

Review changes to your workspace

The audit log records changes to your workspace and who made them: a member or the system. Read it with GET /v1/audit-logs, abusezero audit-logs list in the AbuseZero CLI, or abusezero_list_audit_logs on the AbuseZero MCP server. In the dashboard, it's the Audit trail.

const events = await abusezero.auditLogs({ limit: 50 });
Response (abridged)
{
  "object": "list",
  "data": [
    {
      "object": "audit_event",
      "id": "aud_48213",
      "action": "evaluations.export_requested",
      "actor": "member",
      "created_at": "2026-10-29T15:22:09.000Z"
    }
  ],
  "next_cursor": null
}

Check claims awaiting an outcome

If a benefit waits for outcome reports, outcomes that stay in awaiting_outcome past their due_at, or that reach outcome_unknown, mean your reports aren't arriving. List them with GET /v1/outcomes; Outcome states explains each state. See Report outcomes.

const outcomes = await abusezero.outcomes({ limit: 100 }) as { data: { state: string }[] };
const unreported = outcomes.data.filter(outcome => outcome.state === "outcome_unknown").length;

Schedule automated checks

Run one check on a schedule and alert your team when it finds something. It uses the SDK's additional methods.

jobs/abusezero-health.ts
import { abusezero } from "../lib/abusezero";
import { alertTeam } from "../lib/alerts";

export async function checkAbuseZeroHealth() {
  const browser = await abusezero.browserCollection() as { issue: string | null; issue_since: string | null };
  if (browser.issue) {
    await alertTeam(`AbuseZero browser setup: ${browser.issue} since ${browser.issue_since}`);
  }

  const outcomes = await abusezero.outcomes({ limit: 100 }) as { data: { state: string }[] };
  const unreported = outcomes.data.filter(outcome => outcome.state === "outcome_unknown").length;
  if (unreported > 0) {
    await alertTeam(`AbuseZero: ${unreported} recent outcomes were never reported`);
  }
}

alertTeam stands for your own alerting.

Verify your integration

Run checkAbuseZeroHealth once by hand. With a healthy integration, it sends no alerts. Then schedule it to run regularly, for example every hour, alongside your own alerts on failed AbuseZero calls.

How is this guide?

Last updated on

On this page