Authentication
How to obtain a token and which header each Evercam API expects.
Evercam issues a single JSON Web Token that most of the platform accepts. The
header you send it in, however, differs between services — getting this wrong
is the most common cause of an unexpected 401.
Obtaining a token
Returns the user record plus a token field.
curl -X POST "https://media.evercam.io/v2/auth/login" \
-H "Content-Type: application/json" \
-d '{"username": "you@example.com", "password": "…"}'Which header each API expects
The differences below are deliberate and each service enforces its own.
| API | Header |
|---|---|
| Dash | Authorization: Bearer <jwt>, or X-API-ID + X-API-KEY |
| AI | Authorization: Bearer <jwt>, or x-api-key: <jwt> |
| Labs | Authorization: Bearer <jwt> |
| ExNVR | Authorization: Bearer <access_token> from that device |
| MCP | Authorization: Bearer <token> — an OAuth token or the same JWT; API keys not accepted |
The MCP server at https://mcp2.evercam.io/mcp
resolves its credential per request. Interactive clients get one by signing in
over OAuth, which is the route to prefer; the same JWT used everywhere else also
works, for scripts and CI. Either way it is a bearer header — the X-API-ID /
X-API-KEY pair that Dash allows is rejected there.
ExNVR is separate
ExNVR runs on your own recorder rather than Evercam's infrastructure. It issues
its own access token from POST /api/users/login on the device, and platform
tokens do not work against it.
For media URLs that cannot set headers — HLS segments and snapshots — ExNVR
also accepts the token as a ?token= query parameter.