Skip to main content
POST
/
v1
/
session
/
otp
/
check
Check standalone OTP
curl --request POST \
  --url https://{appId}.session.prelude.dev/v1/session/otp/check \
  --header 'Content-Type: application/json' \
  --header 'X-Verification-Token: <api-key>' \
  --data '
{
  "code": "<string>",
  "challenge_token": "<string>"
}
'
{
  "challenge_token": "<string>"
}

Authorizations

​
X-Verification-Token
string
header
required

Verification token returned in the X-Verification-Token response header of POST /v1/session/otp. Replay it on /otp/check and /otp/retry to identify the verification context.

The legacy verificationCookieAuth cookie is still accepted as a fallback for SDKs that don't yet read the header.

Body

application/json
​
code
string
required

The OTP code to verify.

Example:

"123456"

​
challenge_token
string

The challenge token. Required when the verification token carries a step-up context (i.e., OTP was initiated via a step-up flow); omit for standalone OTP verification.

Example:

"eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9..."

Response

OK

​
challenge_token
string
required

A new challenge token. The token's grant_mode claim determines what to do next:

  • session-start — finalize the login via the Finalize login endpoint.
  • single-use / session-bound / profile-bound — the next step-up step (or completion). The frontend SDKs handle this routing automatically.

For the OAuth-email-link flow (provider with verify_email=true) this endpoint also returns a session-start token, which the SDK finalizes against the original PKCE code_verifier.

Example:

"eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9..."