Go-live checklist

Secure your keysCopy Anchor Link

• Secret and restricted keys exist only in server code and your secrets manager. None is in a browser bundle, a mobile app or a repository.
• Your production service uses a restricted key with only the scopes it calls, such as evaluations:create and outcomes:write. See Keys and access.
• Browser code uses only your publishable key (pk_…).
• You know each key's expiry date, if it has one, and who replaces it. Keys are managed in Developers → API keys.

Review each benefitCopy Anchor Link

• Each benefit uses the protection level or policy you intend. Read each one with GET /v1/benefits or abusezero benefits list in the AbuseZero CLI.
• protection_mode is protect. A benefit left in observe allows every claim. See Protection mode.
• eligibility matches how often a user may claim the benefit.
• outcome_tracking matches your flow. Use report_outcome when granting can still fail after an allow. See Report outcomes.
• automation, bot_evidence and allowed_agents are set the way you want. See Add a bot check and Verify AI agents.

Integrate every claim pathCopy Anchor Link

• Every place a user can receive the benefit evaluates the claim first: web sign-up, in-app upgrades, mobile apps and your own API.
• Each claim has a stable claim_id, and each request an Idempotency-Key that you store with the claim.
• Every evaluation sends every identifier you have, including the real visitor IP from your trusted proxy chain. See Send identifiers.
• email_verified and phone_verified are true only when your app verified them.
• A deny shows the person a neutral message, and your team can see reason.code. See Reason codes.

Check browser protectionCopy Anchor Link

• Every site where people claim a benefit is in your site list, in Developers → Browser setup or PATCH /v1/browser-collection.
• Your Content Security Policy includes the sources shown in Browser setup.
• Every evaluation sends identifiers.device_token, including when the AbuseZero browser SDK reports no browser data.
• Browser setup shows your sites as seen, with no open issue. See Set up browser protection.

Import outcome historyCopy Anchor Link

• Benefits you granted before AbuseZero are imported, so earlier users are recognized from day one. See Import outcome history.
• If a benefit waits for outcome reports, your code reports every outcome before outcome.due_at.

Set the outage behaviorCopy Anchor Link

• You chose an outage behavior on purpose. See Handle outages and retries.
• Retries reuse the same Idempotency-Key and request body.
• Skipped evaluations have their own branch and alert the workspace owner.
• Your logs keep the X-Request-ID of every AbuseZero call.

Confirm billingCopy Anchor Link

• The workspace owner has checked credits and plan limits in Workspace settings → Billing & Subscriptions.
• Your team knows that every evaluation, preview and Test console run uses credits.

Run final verificationCopy Anchor Link

Run one real claim through each claim path, then open each evaluation with GET /v1/evaluations/{id}:

• result is the one you expect, and mode is protect.
• inputs shows received for every identifier you send.
• browser_data is collected for claims from your web pages.
• policy.id and policy.version match the policy you reviewed.

Then claim the same benefit again as the same user with a new claim_id. The second evaluation is denied.

Finally, set up the scheduled check in Monitor your integration, so your team hears about a problem before your users do.