Test mode and feedback
Test mode
- Integrate with
sk_test_/pk_test_keys. - Fire each event type you use at least once (the canonical payloads are fine).
- In the dashboard, flip the mode toggle to Test and confirm the events appear with verdicts and reasons.
- Trigger your
blockpath deliberately — add a blocklist entry in Settings → Lists (your own email domain works) — and confirm your UX shows the generic rejection. - Swap the env var to live keys. Nothing else changes.
Test-mode data is fully isolated — test velocity counters and clusters never touch live decisions.
Reporting outcomes back (feedback)
Feedback is what makes the identity graph sharp for you specifically:
confirmed_abusemarks the user’s whole linked cluster; future linked accounts get blocked.false_positiveis the metric we hold ourselves to weekly — send it even when it feels minor.- Safe to retry — no idempotency key needed. The SDK retries once on a 5xx
or network failure, and the API deduplicates on
(event id, outcome): reposting the same outcome returns{"ok": true}without recording a second row or double-counting the cluster mark. Replay whole batches freely. The dedupe key is the outcome, not the call — sendingfalse_positivefor an event you earlier reported asconfirmed_abuseis new, distinct feedback. - Unlike
verdict(),feedback()throws on failure rather than degrading — silently losing abuse feedback would be worse than an exception.
Next
- Handling verdicts — the review flow, webhooks, checkout patterns.
- Reason codes — what every code means and what to do about it.