Retrieve a stored event
Fetch a previously judged event by the id returned from POST /v1/verdict. Scoped to the tenant and mode of the key you present: an event created with a test key is invisible to a live key, and vice versa (it 404s rather than 403s).
Authentication
Authorization: Bearer sk_live_… (or sk_test_…). Server-side only — never ship a secret key to a browser or a mobile app. The key determines the tenant and the mode; there is no mode parameter on any request.
Path parameters
The event id returned by POST /v1/verdict, e.g. evt_01J8Z3K9….
Response
The event id. Persist it alongside your user or charge — it is the join key for the review.resolved webhook and for GET /v1/events/{id}.
allow: proceed. review: proceed anyway, and be ready to revoke when the review.resolved webhook says so. block: stop the flow with a generic error — do not tell the user which signal tripped.
Why. Ordering is not significant and an empty array is normal on allow. The reasons explain the decision; they are not the decision.
The rules version that produced this decision, e.g. 2026-08-18.0. Useful when correlating a change in your block rate with a change on our side.
Optional advice that rides alongside the verdict — today only on login. Absent when there is nothing to advise. It does not change what the verdict means: ignore it and nothing breaks. step_up means ask for a second factor rather than refuse, which is the right answer to a sign-in from an unrecognised device.