Verify

Orbit Verify is a turnkey OTP (one-time password) verification service. Send verification codes via SMS, WhatsApp, Voice, Email, Viber, Telegram, RCS, or a missed-call Flashcall — Orbit handles code generation, delivery, expiration, brute-force protection, and validation. To understand how a verify works in a real flow, start here; the behavior of endpoints and profiles follows.

Formats and recipient requirements

POST /verify/send requires to and accepts channel, code_length, max_attempts, country, profile_id, channels, fallback_config, locale, custom_code, and device_token. Every recipient shape runs through the same resolver the /check endpoint uses.

Field	Value
`to`	Required. E.164 phone number (e.g. `+14155552671`) or a reachable email address.
`channel`	`sms` (default), `whatsapp`, `email`, `voice`, `viber`, `telegram`, `rcs`, `flashcall`, `silent`, `sna`, `magic_link`. The delivery channels split into phone-only or email-only recipient shapes (see below).

Recipient shape by channel. The to resolver rewrites national-format numbers to E.164 when a country hint is present; short codes are rejected up-front (they are sender IDs, not destinations).

Channel	Recipient format	Behavior
`sms`	E.164 phone	SMS text message with the code
`whatsapp`	E.164 phone	WhatsApp message with the code; runs the WhatsApp Business readiness gate (WABA must be connected with `access_token`, `phone_number_id`, `waba_id`)
`email`	Email (RFC 5322)	Email with the code and branded template
`voice`	E.164 phone	Automated voice call that reads the code aloud (TTS)
`viber`	E.164 phone	Viber message with the code
`telegram`	E.164 phone	Telegram Gateway API `sendVerificationMessage`; requires `DEVOTEL_TELEGRAM_GATEWAY_API_KEY`
`flashcall`	E.164 phone	Missed-call OTP (the trailing CLI digits are the code); phone recipient, origin via Devotel softswitch when a CLI pool is provisioned
`rcs`	E.164 phone	RCS Business Message via a verified RBM agent (logo + checkmark); fail-closed until an RCS provider is registered

Limits and validation windows

These bounds stop misconfiguration at send time and they are the same ones the profile service enforces. The /check endpoint mirrors the same limits on attempts and code length.

Limit	Default	Range	Enforcement
Code length	6 digits	4–8	`code_length` on the send body; profile `codeLength` locked to a 4/6/8 literal
Max attempts per code	3	1–10	`max_attempts` on the send body; the `/check` endpoint consumes one attempt per call
TTL (expiry)	600s (10 min)	profile `expirySeconds` 30–3600s	On a verify profile only — not a send-body parameter (see below)
Fallback-chain length	—	1–4 channels	`channels[]` index 0 is the primary, indices 1–N retry in order
Per-channel timeout	60s	10–600s	`fallback_config.channel_timeout_seconds` (async fallback engine)
Attempts per channel in a chain	1	1–3	`fallback_config.max_attempts_per_channel`
Bulk recipients	—	1–1000	`recipients[]` per batch (`POST /verify/bulk`)
`custom_code`	—	—	Sandbox/test-mode keys only; live keys are strictly rejected with `403 CUSTOM_CODE_FORBIDDEN`

Why expirySeconds is profile-only. The /verify/send body has no expiry field. Direct sends expire after the default 600s. To change the TTL, create a verify profile with expirySeconds and pass its profile_id on the send; the profile owns the TTL because the fallback engine and per-channel templates also live on the profile. When a profile is passed and the profile expires, the request is rejected — not silently hot-swapped. That is also why the profile update path re-validates expirySeconds instead of computing a synthetic default.

Rate-limit + fraud surface

Verify runs the full send pipeline in service of the /verify/send and /verify/bulk calls. Every recipient flows through the same per-recipient checks.

Rate limiting — per-recipient hourly cap (default 5/hour; tuned via a verify profile rateLimitPerHour, org-level verify_recipient_hourly_cap, or platform default). 429 VERIFY_RECIPIENT_RATE_LIMITED receipts are per-recipient, not per-batch.
Velocity limits — the verify profile fraud.velocityPerHour / fraud.velocityPerDay (values 1–100 and 1–1000) and the composite-risk verifier (lib/verify-fraud-guard.ts) that scores SIM-swap, port-event, and CAMARA possession.
Resend cooldown — VERIFY_RESEND_COOLDOWN runs as a SET NX guard (30s per recipient) before the hourly INCR, so a resend burst does not consume an hourly slot.
VoIP line-type guard — a tenant opt-in verify_line_type_policy allows voip_sms / voip_voice to be off (default), warn, or block, so VoIP line-types are gated on SMS and voice only by tenant choice. The default is off.

Verify-specific fraud pre-flight

Before rate-limit/increment or billing deduct, /verify/send runs the fraud gate. SIM-swap pre-flight returns a synchronous 403 SIM_SWAP_DETECTED with last_swap_date and block_window_hours in details. No verification row is created and no verification.failed webhook fires — wire step-up (login attempts) to the 403 response, not to the webhook. The endpoint rate-limits are separate (verify-send = 20/min, verify-bulk = 2/min, verify-check = 60/min, verify-fraud-score = 20/min, verify-fraud-gate = 20/min).

Fraud Score dip — `POST /verify/fraud-score`

Score one E.164 number’s SIM-swap and line-type fraud risk without spending an OTP. The body takes a single phone_number; a mis-formatted (non-E.164) number fails fast with a 422 before a lookup dip is burned.

curl -X POST https://api.orbit.devotel.io/api/v1/verify/fraud-score \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{ "phone_number": "+14155550100" }'

A 2xx returns the composite under data (the meta block is trimmed here):

{
  "data": {
    "phone_number": "+14155550100",
    "risk_score": 82,
    "risk_level": "high",
    "recommendation": "block",
    "reasons": ["sim_swap_recent", "line_type_voip"],
    "sim_swap": {
      "risk_level": "high",
      "last_swap_date": "2026-09-12T14:03:00Z",
      "swapped": true
    },
    "line_type": "voip",
    "carrier": { "name": "Example Mobile", "type": "voip" },
    "roaming": false,
    "country": "US",
    "lookup_available": true
  }
}

risk_score runs 0–100 (higher is riskier). risk_level bands it: low under 25, medium 25–49, high 50+. recommendation maps 1:1 from the band — allow, step_up, or block — and is advisory only: your send flow decides. reasons carries the machine-readable codes (SIM-swap recency, VOIP line-type, roaming) that drove the score.

Fail-open on an unavailable lookup. When the number-intelligence lookup cannot run (invalid number, gateway timeout, no operator broker for the region) the response still returns 2xx with lookup_available: false, risk_score: 0, and recommendation: "allow". Treat that as no signal, not a confirmed-clean verdict — the flag is how you tell the two apart.

Fraud Gate composite — `POST /verify/fraud-gate`

Fuse the operator-asserted identity signals into one composite verdict you can gate a send (or any transaction) against. The body takes phone_number plus optional access_token (a device-bound 3-legged Silent Auth token — without it the possession signal is skipped), sim_swap_max_age (hours, 1–2400, default 240), number_recycling_max_age (days, 1–2555, default 30), and per-request weights / thresholds overrides that tune the same fusion the risk-score kernel uses.

curl -X POST https://api.orbit.devotel.io/api/v1/verify/fraud-gate \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "phone_number": "+14155550100",
    "sim_swap_max_age": 240,
    "number_recycling_max_age": 30,
    "weights": { "simSwapped": 40, "numberRecycled": 20 },
    "thresholds": { "review": 25, "deny": 50 }
  }'

{
  "data": {
    "phone_number": "+1415****",
    "decision": "deny",
    "risk_score": 82,
    "risk_level": "high",
    "reasons": ["sim_swap_recent", "number_recycled_recent"],
    "signals_evaluated": ["simSwapped", "numberRecycled"],
    "signals_unavailable": ["numberVerified"],
    "headline_signals": {
      "resolved": ["sim-swap", "port-event"],
      "unavailable": ["silent-auth"]
    }
  }
}

decision is the composite verdict — allow, review, or deny — computed against your thresholds. phone_number is echoed masked. signals_unavailable lists the fusion keys the operator could not answer this dip; without an operator broker configured (or a missing access_token for possession) those degrade fail-closed into the unavailable list rather than reading as a clean pass.

Node.js SDK escape hatch

The typed SDK has no per-dip helper for these two endpoints — call them through the generic orbit.request() escape hatch (it attaches the API key, retries 429/5xx, and sends an idempotency key on every POST):

import { Orbit } from "@devotel-orbit/node";

const orbit = new Orbit({ apiKey: process.env.ORBIT_API_KEY });

const score = await orbit.request("POST", "/verify/fraud-score", {
  phone_number: "+14155550100",
});

const gate = await orbit.request("POST", "/verify/fraud-gate", {
  phone_number: "+14155550100",
  sim_swap_max_age: 240,
  number_recycling_max_age: 30,
  thresholds: { review: 25, deny: 50 },
});

Error and rate-limit behaviour

Condition	Response	Handling
Non-E.164 `phone_number`	`422`	Rejected before any lookup dip runs — fix the format
SIM swap blocks a send	`403 SIM_SWAP_DETECTED`	Fire `last_swap_date` + `block_window_hours` in `details`; no verification row, no webhook
Dip rate limit exceeded	`429`	20 dips/min per tenant on each of `fraud-score` and `fraud-gate`
Operators / lookup unreachable	`2xx` degraded	`fraud-score` → `lookup_available: false`, score 0/`allow`; `fraud-gate` → operator signals moved into `signals_unavailable` (fail-closed)

Both dips are capped at 20 per minute per tenant each. A 429 is per-endpoint, not shared across the two.

Webhook semantics

Subsequent /check attempts land on verification.checked (any attempt, success or not) so anti-fraud scoring can be driven from the stream. The one-time terminal approvals are the CAS-guarded operations:

verification.approved — a /check matched the code; fires exactly once per verification via the compare-and-set (CAS) transition gate
verification.failed — max_attempts were exhausted or the verification moved to a terminal unsuccessful state
verification.sent — the code was handed to the provider successfully

Factor channels emit their own events (e.g. totp.create, backup_code.verify, push.factor.verify, passkey.challenge.verify) — see the API reference for the secure factor-event catalog.

Channel capability at a glance

The first group delivers an OTP over a carrier; the second group are non-delivery / factor channels that prove possession without carrying an OTP.

Delivery channels

Channel	Delivery Method
`sms`	SMS text message with the code
`whatsapp`	WhatsApp message with the code
`voice`	Automated voice call that reads the code aloud
`email`	Email with the code and branded template
`viber`	Viber message with the code
`telegram`	Telegram message with the code
`rcs`	RCS Business Message with the code through a branded verified-sender agent (logo + checkmark). Fail-closed until an RCS provider is registered.
`flashcall`	Missed-call OTP — a short outbound call from a rotating caller-ID pool, dropped before pickup, whose trailing caller-ID digits are the code. The call originates over the Devotel softswitch; until a CLI pool is provisioned it fails closed with `503 SERVICE_UNAVAILABLE` (`details.reason: "PROVIDER_NOT_WIRED"`, same caveat as `sna`)
`silent`	Network-based silent verification (lookup-then-fallback heuristic)
`sna`	Silent Network Authentication — MNO challenge/response possession proof via the GSMA Open Gateway / CAMARA broker. Pass a device-bound `device_token` it returns `status: "verified"` with no OTP. Without a token it fails closed with `503 SERVICE_UNAVAILABLE` (`details.reason: "PROVIDER_NOT_WIRED"`)
`magic_link`	Email-delivered single-use HTTPS link (Stytch / WorkOS / Auth0 parity)

Factor channels

Channel	Behaviour
`totp`	RFC 6238 authenticator-app factor (30s step, ±1 step skew)
`push`	Push-factor MFA via device public-key + signed-challenge
`backup_code`	Single-use recovery codes (hashed at rest)

Sending channel: "totp", "push", or "backup_code" to POST /verify/send does not issue an OTP — the send endpoint short-circuits with a typed 422 / 400 to the matching factor endpoint below. Those channels are possession-of-secret factors with their own lifecycle.

Send a Verification Code

curl -X POST https://api.orbit.devotel.io/api/v1/verify/send \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155552671",
    "channel": "sms",
    "code_length": 6
  }'

Response

{
  "data": {
    "verification_id": "vrf_3f1c0b2a8e4d4f7a9c2b1e6d5a4c3b2a",
    "status": "pending",
    "channel": "sms",
    "expires_at": "2026-03-08T00:10:00Z"
  }
}

Fallback chain + fallback config

curl -X POST https://api.orbit.devotel.io/api/v1/verify/send \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155552671",
    "channel": "sms",
    "channels": ["sms", "voice", "email"],
    "fallback_config": {
      "channel_timeout_seconds": 60,
      "max_attempts_per_channel": 1
    }
  }'

channels[] index 0 is the primary; the rest are tried in order when the first times out or fails. fallback_config activates the async fallback engine (scheduler-verify-fallback). With no fallback_config, the chain runs synchronously inside the same /verify request.

Bulk send body

POST /verify/bulk fans out up-to-1000 recipients per call. The endpoint rate-limits bulk to 2/min (vs 20/min for /verify/send) because one call can mint up to 1000 OTPs — operators can bump via per-org override.

{
  "recipients": ["+14155552671", "+442071234567"],
  "channel": "sms",
  "profile_id": "vp_1c2b3a4d5e6f7g8h"
}

Bulk response envelope. The HTTP status reflects the batch outcome: 201 when every recipient sent, 207 (Multi-Status) on partial success, and 400 when every recipient failed for a caller reason, or 503 when every recipient failed because of a genuine upstream delivery outage (retryable, matching verify/send’s per-recipient contract).

{
  "data": {
    "results": [
      { "to": "+14155552671", "status": "pending", "verification_id": "vrf_3f1c0b2a8e4d4f7a9c2b1e6d5a4c3b2a" },
      { "to": "+442071234567", "status": "failed", "error": "VERIFY_RECIPIENT_RATE_LIMITED" }
    ],
    "sent_count": 1,
    "failed_count": 1
  }
}

Check a Verification Code

curl -X POST https://api.orbit.devotel.io/api/v1/verify/check \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "verification_id": "vrf_3f1c0b2a8e4d4f7a9c2b1e6d5a4c3b2a",
    "code": "482901"
  }'

Response

{
  "data": {
    "verification_id": "vrf_3f1c0b2a8e4d4f7a9c2b1e6d5a4c3b2a",
    "status": "approved",
    "channel": "sms"
  }
}

Every /check call consumes one attempt. max_attempts exhausted (default 3) terminates the verification; verification.approved only lands on a successful match.

MFA Factors

Beyond OTP send/check, Verify ships phishing-resistant and possession-of-secret MFA factor surfaces for end-tenant users. These factors carry no carrier delivery and no wallet deduct — they validate proof-of-possession against a server-side secret or device key pair. Every factor endpoint requires an authenticated request and is isolated to your organization — a factor created by one tenant is never visible to another. The scope requirement depends on the factor type:

TOTP and backup-code write operations (create, verify, delete, and recovery-code regeneration) require the verify:write scope. Dashboard (session) callers must also hold an owner, admin, or developer role.
TOTP and backup-code list (read) endpoints, along with every Verify Push and Passkey endpoint, are gated by authentication and per-tenant rate limiting only. They do not require an additional verify:write or verify:read scope, so any authenticated key scoped to the tenant can call them — restrict which keys reach these flows accordingly.

The factor suite is API-only by design — it has no dashboard screen. TOTP, backup codes, passkeys (WebAuthn / FIDO2), and push are enrolled, verified, and revoked from inside your own application, where the end user is present to scan a QR code, run a WebAuthn ceremony, or approve a push prompt on their device. Drive them straight from the endpoints below or the SDK. (The Verify dashboard covers OTP send/check, profiles, and analytics; the 2FA control under Settings → Security protects your Orbit login and is separate from these end-user factors.)

TOTP (authenticator app)

RFC 6238 authenticator-app factors (Google Authenticator, Authy, 1Password, etc.). Creating a factor returns the otpauth:// URI for QR rendering plus the base32 secret once — subsequent reads return metadata only. Ten single-use recovery codes are minted on creation and surfaced once; only their SHA-256 hashes are persisted.

Method	Path	Purpose
`GET`	`/verify/factors/totp`	List TOTP factors
`POST`	`/verify/factors/totp`	Create a factor (returns `otpauth://` URI + secret once)
`POST`	`/verify/factors/totp/{id}/verify`	Validate a 6-digit code (30s step, ±1 step skew)
`DELETE`	`/verify/factors/totp/{id}`	Delete a factor
`POST`	`/verify/factors/totp/{id}/recovery-codes/regenerate`	Invalidate and re-mint 10 recovery codes

Backup codes

Single-use, hashed-at-rest recovery codes for users who have lost their device + SMS access. Creating a factor mints 10 plaintext codes returned once; the server stores SHA-256 hashes only. Each code can succeed at most once (enforced by an UPDATE ... WHERE consumed_at IS NULL gate), and verify responses return remaining_count so your UI can prompt regeneration.

Method	Path	Purpose
`GET`	`/verify/factors/backup-codes`	List backup-code factors
`POST`	`/verify/factors/backup-codes`	Mint 10 single-use codes (returned once)
`POST`	`/verify/factors/backup-codes/{id}/verify`	Consume one code (returns `remaining_count`)
`DELETE`	`/verify/factors/backup-codes/{id}`	Delete a factor (idempotent)

Verify Push

Phishing-resistant MFA via a device public-key + signed-challenge flow (mirrors Twilio Verify factor.type="push"). Register a device public key, issue a challenge, then verify the signed nonce returned by the device.

Method	Path	Purpose
`POST`	`/verify/push/factors`	Register a device public key
`POST`	`/verify/push/factors/{factorId}/challenges`	Issue a new challenge
`POST`	`/verify/push/challenges/{challengeId}/verify`	Submit a signed nonce
`POST`	`/verify/push/factors/{factorId}/revoke`	Revoke a paired device

Passkeys (WebAuthn / FIDO2)

Phishing-resistant passkey factors. The registration and authentication ceremonies follow the WebAuthn spec; attestation/assertion verification (CBOR / COSE / signature) runs server-side.

Method	Path	Purpose
`POST`	`/verify/passkey/registration/options`	Issue a WebAuthn registration ceremony
`POST`	`/verify/passkey/registration/verify`	Verify attestation, create the factor
`POST`	`/verify/passkey/authentication/options`	Issue a WebAuthn authentication ceremony
`POST`	`/verify/passkey/authentication/verify`	Verify the assertion, bump the counter
`POST`	`/verify/passkey/factors/{factorId}/revoke`	Revoke a paired passkey

Magic Link

Email-delivered single-use HTTPS link (Stytch / WorkOS / Auth0 parity) instead of a typed code. Send with channel: "magic_link" and an email to; Orbit emails a signed link. The user’s click is consumed by the public, unauthenticated endpoint:

Method	Path	Purpose
`POST`	`/verify/send` (`channel: "magic_link"`)	Email a signed single-use link
`GET`	`/public/verify/magic-link/consume?token={token}`	Consume the link and approve the verification

The token is a constant-time HMAC-signed payload; the consume endpoint approves the underlying verification on success and rejects tampered, expired, or already-used tokens.

Features

Auto-generated codes — secure random codes (4–8 digits)
Multi-channel delivery — SMS, WhatsApp, Voice, Email, Viber, Telegram, RCS, Flashcall, plus silent and sna for device-fraud-sterile checks
Channel fallback — automatic retry on a different channel if the first times out or fails
Rate limiting — built-in protection against brute-force attacks
Expiration — configurable TTL via profiles (default 10 minutes / 600s, max 3600s)
Attempt limits — configurable max verification attempts per code (1–10, default 3)
Locale support — localized message templates in 25 languages
Fraud detection — SIM-swap pre-flight, VoIP-type gating (tenant opt-in), velocity thresholds, composite risk, and offline fraud-score scoring

Configuration options (send body)

These are the body parameters accepted by POST /api/v1/verify/send (sendVerificationSchema). The profile object mirrors these fields to make them tenant-tunable (codeLength, expirySeconds, rateLimitPerHour, templates, fallbackConfig).

Parameter	Type	Default	Description
`to`	string	—	Required. Recipient phone number (E.164) or email address.
`channel`	string	`sms`	Delivery channel: `sms`, `whatsapp`, `email`, `voice`, `viber`, `telegram`, `rcs`, `flashcall`, `silent`.
`code_length`	integer	6	Number of digits (4–8).
`max_attempts`	integer	3	Maximum verification attempts allowed for this code (1–10).
`country`	string	—	ISO 3166-1 alpha-2 hint used to parse national-format numbers into E.164 (e.g. `TR`).
`profile_id`	string	—	Verify profile to apply (templates, `expirySeconds`, fallback config, branding). Configure profiles end to end in the Verify profiles guide.
`channels`	string[]	—	Ordered fallback chain (min 1, max 4). Index 0 is the primary channel; the rest are tried in order.
`fallback_config`	object	—	Async fallback engine config — `{ channel_timeout_seconds: 10–600 (default 60), max_attempts_per_channel: 1–3 (default 1) }`. Pairs with `channels`.
`locale`	string	—	2-letter language code for the localized fallback message/TTS (e.g. `en`, `de`, `es`). Region tags (`es-MX`) are rejected.
`custom_code`	string	—	Sandbox/test-mode only — fixed OTP digits (must equal `code_length`). Rejected with live keys.
`device_token`	string	—	Device-bound CAMARA token for `channel: "sna"`.

Code expiry is not a /send parameter. Direct sends expire after the default 600s (10 minutes). To change the TTL, set expirySeconds on a verify profile and pass its profile_id — there is no expiry field on the send body.

Webhook Events

Event	Description
`verification.sent`	The code was successfully handed to the provider
`verification.approved`	A `/check` call matched the code — fires exactly once per verification (CAS-guarded)
`verification.failed`	`max_attempts` exhausted with no match
`verification.checked`	Any `/check` attempt landed — successful or not (useful for audit / fraud scoring)
`verification.fallback_triggered`	The async fallback engine advanced to the next channel in the chain
`verification.fallback_exhausted`	Every channel in the fallback chain was tried without an `approved` status

A SIM-swap pre-flight block does not emit a webhook. When the pre-flight check rejects a send, /send returns a synchronous 403 SIM_SWAP_DETECTED with last_swap_date and block_window_hours in the response details. No verification row is created and no verification.failed event fires, so wire failure/step-up triggers to the 403 response rather than the webhook.

Next steps

Verify profiles: fallback chains and advanced factors — configure an ordered SMS → WhatsApp → voice chain, code length/TTL, per-channel templates, and pair the profile with push, TOTP, passkey, or voice-biometrics factors.
Verify integration without our SDK — the plain-HTTP send/check flow with the full error matrix and webhook walkthrough.
Troubleshooting: verify OTP — resend cooldowns, recipient caps, VoIP gating, and failover behavior you hit in production.
Verify API reference — every endpoint, including profile CRUD and the factor suites.
Verify audit log approvals — OTP changes that require an operator action.

​Verify

​Formats and recipient requirements

​Limits and validation windows

​Rate-limit + fraud surface

​Verify-specific fraud pre-flight

​Fraud Score dip — POST /verify/fraud-score

​Fraud Gate composite — POST /verify/fraud-gate

​Node.js SDK escape hatch

​Error and rate-limit behaviour

​Webhook semantics

​Channel capability at a glance

​Delivery channels

​Factor channels

​Send a Verification Code

​Response

​Fallback chain + fallback config

​Bulk send body

​Check a Verification Code

​Response

​MFA Factors

​TOTP (authenticator app)

​Backup codes

​Verify Push

​Passkeys (WebAuthn / FIDO2)

​Magic Link

​Features

​Configuration options (send body)

​Webhook Events

​Next steps

Verify

Formats and recipient requirements

Limits and validation windows

Rate-limit + fraud surface

Verify-specific fraud pre-flight

Fraud Score dip — `POST /verify/fraud-score`

Fraud Gate composite — `POST /verify/fraud-gate`

Node.js SDK escape hatch

Error and rate-limit behaviour

Webhook semantics

Channel capability at a glance

Delivery channels

Factor channels

Send a Verification Code

Response

Fallback chain + fallback config

Bulk send body

Check a Verification Code

Response

MFA Factors

TOTP (authenticator app)

Backup codes

Verify Push

Passkeys (WebAuthn / FIDO2)

Magic Link

Features

Configuration options (send body)

Webhook Events

Next steps