Forty-six built-in blocks. Seven families. One page to tell you which family solves your problem so you can go straight to the right reference.
The seven families
Section titled “The seven families”Blocks that verify identity factors — passwords, OTPs, WebAuthn passkeys, and multi-factor challenges. These are the load-bearing steps in every login and registration flow. Reach for an Auth block whenever you need the platform to confirm that a user is who they say they are. The family includes 11 blocks: password_check, mfa, channel_otp_send, channel_otp_verify, webauthn_begin, webauthn_finish, check_mfa_status, require_mfa, require_mfa_enroll, credential_set, and password_update.
Use it when — you need to verify a password, send or confirm an OTP, prompt for a second factor, or update a user's credential.
Blocks that score and classify the incoming request before you decide what to do with it. They aggregate signals — IP reputation, bot patterns, failed-attempt counts, breached-password lists — into a recommendation your next Decision block can act on. The family includes 7 blocks: risk_evaluate, ip_reputation, bot_detection, brute_force, breached_password, email_validation, and password_policy.
Use it when — you want to gate on request quality before allowing a login, enforce password rules at registration, or build a step-up path when a signal fires.
Identity
Section titled “Identity”Blocks that read, create, and update user records. They're the bridge between what the user typed and the identity stored in the platform. The family includes 8 blocks: identity_lookup, identity_create, profile_update, update_user, check_mfa_status, email_verification, verification_send, and verification_check.
Use it when — you need to look up who just typed their email, create an account, patch a profile field, or confirm an email address.
Session
Section titled “Session”Blocks that mint and revoke sessions and tokens. The family includes 7 blocks: issue_session, issue_tokens, refresh_token_validate, session_revoke, finalize, social_oidc_redirect, and social_oidc_callback.
Use it when — you're at the end of a successful authentication and need to hand the user a session JWT or OAuth2 token pair, or when you're handling a social login redirect.
Control flow
Section titled “Control flow”Blocks that route the engine to the next step based on state values. They never write to user-visible state — they just decide which branch runs. The family has 3 blocks: decision, condition, and switch. See Control flow blocks for the full reference.
Use it when — you need if/else branching, multi-arm conditionals, or routing on a risk score.
Notification
Section titled “Notification”Blocks that trigger outbound communication or external calls. They keep the flow moving — the engine continues to the next block on success. The family includes 6 blocks: call_webhook, send_email, notify, channel_otp_send, password_recovery_send, and log_event.
Use it when — you want to fire a webhook to your CRM, queue a welcome email, send a recovery link, or emit a custom audit event.
Terminal
Section titled “Terminal”Blocks that end the flow. Once the engine reaches a terminal block it stops walking and returns a result. The family has 2 blocks: allow and deny. Most flows end at issue_session (on the happy path) or deny (on rejection); allow is used as a sentinel in branching logic. See Terminal blocks for the full reference.
Use it when — you need to explicitly accept or reject the request at the end of a branch.
Two blocks worth knowing up front
Section titled “Two blocks worth knowing up front”Run Action (run_action) — this is the hook into your own JavaScript. Drop one into any stage, pick a saved Custom Action from the dropdown, and the platform executes your code server-side in a sandboxed runtime. Use it for anything the built-in blocks don't cover: domain allowlists, CRM tagging, custom claim injection, disposable-email checks. See Custom actions overview.
Capture Telemetry (telemetry_capture) — this block writes browser context (device fingerprint, IP, GeoIP, user-agent parse) into the event record so downstream risk blocks have signal to work with. The default Login and Registration flows include it automatically; you normally don't add it yourself, but you can move it or duplicate it in custom flows. Its outputs live under event.request.* and are available to every block that follows.
Quick reference — ten blocks you'll use most
Section titled “Quick reference — ten blocks you'll use most”| Block id | Family | What it does |
|---|---|---|
password_check | Auth | Verifies the user's password and lifts the session to AAL1 |
mfa | Auth | Verifies a second factor (TOTP, SMS-OTP, Email-OTP, WebAuthn) |
risk_evaluate | Risk | Aggregates all active signals into a severity + recommendation |
ip_reputation | Risk | Classifies the client IP (VPN, Tor, datacenter, country) |
identity_lookup | Identity | Finds a user by a trait (email or phone) |
identity_create | Identity | Mints a new identity in the platform |
issue_session | Session | Mints an Aegis-signed session JWT — the typical happy-path terminal |
decision | Control flow | Branches on an expression — the workhorse for risk routing |
call_webhook | Notification | Fires an HTTPS request to your endpoint with SSRF protection |
deny | Terminal | Rejects the request with a configurable reason code |
This table covers the most-used blocks. Every block in all seven families is documented on its category page.
How to find what you need
Section titled “How to find what you need”There are three paths:
- By problem — Recipes is a catalogue of finished flows for common goals: step-up MFA on risk, block disposable email signups, sync new users to a CRM, enforce password rules on registration, and more.
- By family — the seven category pages (Auth, Risk, Identity, Session, Control flow, Notification, Terminal) each cover every block in that family with a full inputs/outputs reference.
- By name — use the search bar (Cmd-K) and type the block name; results include these reference pages and the Recipes that use each block.