Authentication
API keys for verification, session tokens for the dashboard.
There are two kinds of credential, and they are not interchangeable.
API keys
Everything under /v1/verify takes an API key. Send it as a bearer token:
curl https://api.menaverify.com/v1/verify/iban \
-H "Authorization: Bearer $MENAVERIFY_KEY" \
-H "Content-Type: application/json" \
-d '{"value": "AE070331234567890123456"}'Or as its own header, which some HTTP clients handle more comfortably:
curl https://api.menaverify.com/v1/verify/iban \
-H "X-API-Key: $MENAVERIFY_KEY" \
-H "Content-Type: application/json" \
-d '{"value": "AE070331234567890123456"}'Both are equivalent — pick one.
API key format
| Prefix | Cost | Use it for |
|---|---|---|
mv_live_ | Free, unlimited checks | Production and integration use |
All API keys use the same live validation flow. Verification is free, and each key is held to a per-second rate limit.
Handling keys
A key is shown in full exactly once, when you create it. Only a prefix is stored afterwards, so a lost key has to be replaced rather than recovered.
Server-side only
A key sent from a browser or a mobile app is public. Call the API from your backend and pass the result to the client.
Rotating is safe to do gradually: create the replacement, deploy it, then revoke the old one. Revocation takes effect immediately.
Session tokens
The dashboard endpoints under /v1/auth and /v1/account — usage and
key management — take the session token returned by dashboard sign-in, not an
API key:
curl https://api.menaverify.com/v1/account/usage \
-H "Authorization: Bearer $MENAVERIFY_SESSION"Session tokens carry the mvs_ prefix. They exist for the dashboard; an
integration should not need them.
What a rejected credential looks like
A missing, malformed or revoked credential returns 401 with the
unauthorized code. Using a session token where an
API key is expected — or the reverse — returns
forbidden.