Verification (OTP)

The Verify endpoints handle one-time codes end to end — generation, expiry, attempt limits and validation. You never store the code.

Start and check

POST /verify/start sends a one-time code; POST /verify/check validates the code the user typed. The code lives on our side only — you send a destination and get back a masked status, never the code itself. A wrong code is still a 200, with valid: false and the attempts you have left. Codes go out by email, and both calls require the email:send scope. Start accepts an Idempotency-Key, like every write that costs money — a network retry returns the same challenge instead of sending a second code.

cURL

curl -X POST https://api.qsendyx.com/api/v1/verify/start \
  -H "Authorization: Bearer $QUATHOS_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "to": "user@example.com", "channel": "email" }'

Start a verification.

cURL

curl -X POST https://api.qsendyx.com/api/v1/verify/check \
  -H "Authorization: Bearer $QUATHOS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "to": "user@example.com", "code": "481902" }'

Check the code the user typed.

OTP endpoints are a favourite abuse target — a script can trigger thousands of verifications. Rate-limit by user and by destination on your side too, not only by IP. The platform already enforces its own ceiling of at most 3 code sends per destination per hour, but your product knows its users better than any global cap.

Custom services

/verify/start uses a default verification service: a six-digit numeric code, five-minute expiry, five attempts, at most three sends per destination per hour. To change any of that, create your own service with POST /verify/services — code length (4–10), expiry (60–3600 seconds), attempt limit, default channel — and use its id: POST /verify/services/{id}/challenges sends the code, POST /verify/services/{id}/checks validates it.

cURL

curl -X POST https://api.qsendyx.com/api/v1/verify/services/{service_id}/challenges \
  -H "Authorization: Bearer $QUATHOS_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "to": "user@example.com", "channel": "email" }'

Start a verification on a custom service.

cURL

curl -X POST https://api.qsendyx.com/api/v1/verify/services/{service_id}/checks \
  -H "Authorization: Bearer $QUATHOS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "to": "user@example.com", "code": "481902" }'

Check against the same service.

What a verification costs

The message that carries the code is a normal send: email codes follow the same quota rules as any transactional email. Email verifications carry no success fee.

In the test environment nothing is charged.

Previous SMTP relay Next Webhooks