Skip to content

Users

users_stats_get

One snapshot of this product's auth deployment: directory users split by DERIVED status (active, waitlisted, banned, soft-deleted, GDPR-erased), sessions that are live right now, verified second factors, the sign-in success rate over `window`, and an abuse block — lockouts (with the MFA subset), failed sign-ins, detected refresh-token reuse and breached-password sightings.

Tool

users_stats_get

One snapshot of this product's auth deployment: directory users split by DERIVED status (active, waitlisted, banned, soft-deleted, GDPR-erased), sessions that are live right now, verified second factors, the sign-in success rate over `window`, and an abuse block — lockouts (with the MFA subset), failed sign-ins, detected refresh-token reuse and breached-password sightings.

One snapshot of this product's auth deployment: directory users split by DERIVED status (active, waitlisted, banned, soft-deleted, GDPR-erased), sessions that are live right now, verified second factors, the sign-in success rate over `window`, and an abuse block — lockouts (with the MFA subset), failed sign-ins, detected refresh-token reuse and breached-password sightings. The populations are point-in-time; only the sign-in and abuse numbers honour `window`. A rising abuse block against a falling success rate is what credential stuffing looks like from here. `successRate` is null, not 0, when nothing was attempted.

Behavior

HTTP
POST /users/stats/get

Arguments

NameTypeRequiredDescription
windowstringLook-back window for the TIME-BOUNDED numbers — the sign-in counters, the abuse block and `sessions.createdInWindow`: '24h', '7d', '30d' or '90d'. Default '7d'. The user, live-session and factor populations are point-in-time and ignore it.

Response

FieldTypeAlwaysDescription
abuseobjectAbuse signals over the window. Denied origins are deliberately absent: that check fires on unauthenticated traffic and is served by logs and metrics, not by per-product audit rows.
sincestringISO start of that window — the `created_at` floor every counter used.
usersobjectPoint-in-time directory populations by DERIVED status — `user` has no status column, these are computed from `waitlisted` and the ban/delete/erase timestamps.
windowstringThe window the time-bounded numbers were computed over.
factorsobjectEnrolled second factors (TOTP and backup-code batches).
signInsobjectSign-in outcomes over the window, from the audit log.
sessionsobjectDevice sessions.

Try it

One snapshot of this product's auth deployment: directory users split by DERIVED status (active, waitlisted, banned, soft-deleted, GDPR-erased), sessions that are live right now, verified second factors, the sign-in success rate over `window`, and an abuse block — lockouts (with the MFA subset), failed sign-ins, detected refresh-token reuse and breached-password sightings.

When to use

One snapshot of this product's auth deployment: directory users split by DERIVED status (active, waitlisted, banned, soft-deleted, GDPR-erased), sessions that are live right now, verified second factors, the sign-in success rate over `window`, and an abuse block — lockouts (with the MFA subset), failed sign-ins, detected refresh-token reuse and breached-password sightings. The populations are point-in-time; only the sign-in and abuse numbers honour `window`. A rising abuse block against a falling success rate is what credential stuffing looks like from here. `successRate` is null, not 0, when nothing was attempted.

Example

Ask your agent something like this:

One snapshot of this product's auth deployment: directory users split by DERIVED status (active, waitlisted, banned, soft-deleted, GDPR-erased), sessions that are live right now, verified second factors, the sign-in success rate over `window`, and an abuse block — lockouts (with the MFA subset), failed sign-ins, detected refresh-token reuse and breached-password sightings.

The agent will invoke users_stats_get with these arguments:

{}

Esc

Start typing to search the docs.

navigateselect