Authentication

VerifEye REST APIs support two authentication methods.

1. API Key Authentication

VerifEye APIs use API Key authentication with the Authorization header.

Format

Header Format:

Authorization: ApiKey <API-KEY-FROM-DEV-CONSOLE>

Example

curl -X POST "https://verifeye-face-api-eu.realeyes.ai/v1/face/identify" \
  -H "Authorization: ApiKey <API-KEY-FROM-DEV-CONSOLE>" \
  -H "Content-Type: application/json" \
  -d '{
    "image": {
      "bytes": "/9j/4AAQSkZJRgABAQEAYABgAAD..."
    },
    "collectionId": "my-collection"
  }'

2. JWT Bearer Token Authentication

JWT tokens provide time-limited authentication for client-side applications. Tokens are generated using the VerifEye Security API's /token/get endpoint.

Format

Header Format:

Authorization: Bearer <jwt-token>

How to Get a JWT Token

Step 1: Generate Token

curl -X GET "https://verifeye-security-api-eu.realeyes.ai/v1/token/get" \
  -H "Authorization: ApiKey <API-KEY-FROM-DEV-CONSOLE>"

Response:

{
  "token": "eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCJ9...",
  "expiresAt": "2026-01-27T12:00:00Z"
}

Step 2: Use Token in API Requests

curl -X POST "https://verifeye-face-api-eu.realeyes.ai/v1/face/identify" \
  -H "Authorization: Bearer eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCJ9..." \
  -H "Content-Type: application/json" \
  -d '{
    "image": {
      "bytes": "/9j/4AAQSkZJRgABAQEAYABgAAD..."
    },
    "collectionId": "my-collection"
  }'

Managing Your API Keys

Your account can hold up to four API keys. Create and delete them in the VerifEye Developer Console on the API Key page (profile menu → API Key, or Home → View API Keys).

• Every key authenticates. Any key of your account is accepted by every VerifEye API, by the Security API's /token/get and as the client secret of an OpenID Connect integration.
• A flow keeps the key it was started with. A verification started from a URL signed with one of your keys, or a session created with one, signs its result with that key and sends it in the webhook's X-API-Key header. Use a separate key per application, so one can be deleted without affecting the others.
• The primary key is the default where no key can be inferred: the verification links of OpenID Connect sign-ins, the MCP server, the Developer Console's own calls, callers that authenticate with a Bearer token, and sessions started from an unsigned URL. Making another key primary changes only that; links signed with your other keys stay valid. The MCP server picks up a new primary within five minutes.
• Deleting a key rejects its requests within a minute, stops every verification link signed with it on a configuration that requires signed input, non-expiring links and widget snippets included, fails its sessions in flight, and breaks an OpenID Connect integration that uses it as its client secret.
• After a key leaks, rotate every key of the account, not only the leaked one: generate new keys, deploy them, make one of them primary, then delete the old ones.

Last updated: 2026-10-22