Verify registration
AUTHENTICATED BY X-API-Key, not by a bearer token. auth.APIKeyMiddleware REPLACES the usual chain on this route, so there is no user context, no RBAC check and no licence check — and the refusals are common.api_key_required / common.invalid_api_key rather than common.unauthorized / common.rbac_no_rec_access. An OPTIONS request skips the key check entirely. Submit the registration code. A code checked against an address nobody registered, or one already confirmed, is refused exactly as a wrong code is — `400 otp_m.otp_invalid`, `400 otp_m.otp_expired`, or `429 otp_m.cooling_period_active` once the attempt budget is spent — so the refusal names no account state. Attempts against a credential the caller does not own never reach that credential's budget.
Authorization
apiKeyAuth Service API key for the eight pre-authentication user routes. auth.APIKeyMiddleware REPLACES the bearer chain on those routes rather than wrapping it: there is no user context, no RBAC check and no licence check on them.
In: header
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Identify the credential by user_id or by credential_value; at least one is required. POST /v1/users/initiate-registration no longer answers with an identifier — it answers the same opaque acknowledgement whether the address is free or already confirmed on another account — so a client driving registration end to end carries the address it submitted and sends that. user_id remains accepted for callers that already hold one.
Identify the credential by user_id or by credential_value; at least one is required. POST /v1/users/initiate-registration no longer answers with an identifier — it answers the same opaque acknowledgement whether the address is free or already confirmed on another account — so a client driving registration end to end carries the address it submitted and sends that. user_id remains accepted for callers that already hold one.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/v1/users/verify-registration" \ -H "Content-Type: application/json" \ -d '{ "credential_type": "email", "otp": "string" }'{
"message": "Your account has been successfully verified and activated.",
"status": "success"
}{
"message": "Invalid OTP. 2 attempt(s) left",
"status": "invalid"
}{
"status": 401,
"message": "common.api_key_required",
"code": "common.api_key_required",
"class": "business"
}{
"status": 403,
"message": "common.invalid_api_key",
"code": "common.invalid_api_key",
"class": "business"
}{
"message": "Credential already exists",
"status": "duplicate"
}{
"message": "In cooling period for 1 minute, 60 second(s) left",
"status": "cooling",
"wait": 60
}{
"message": "An error occurred while verifying the code",
"status": "error"
}{
"overall_status": "unhealthy",
"message": "Service is shutting down",
"timestamp": "2026-08-27T15:04:05Z"
}AUTHENTICATED BY X-API-Key, not by a bearer token. auth.APIKeyMiddleware REPLACES the usual chain on this route, so there is no user context, no RBAC check and no licence check — and the refusals are common.api_key_required / common.invalid_api_key rather than common.unauthorized / common.rbac_no_rec_access. An OPTIONS request skips the key check entirely. Ask for the registration code again. One answer covers every outcome: a credential still waiting for its code is sent another, and a request that names an address nobody registered, one already confirmed, or an account with no credential is answered identically without sending anything. Send pacing applies to both, so a burst answers `429`. The endpoint is also rate limited per IP.
Next Page