Authentication

Every request to /v1/email/check and /v1/email/bulk is authenticated with a bearer API key, created from the dashboard.

Creating a key

Create an API key from the dashboard's API Keys page. The full key is shown exactly once, at creation — it's never displayed again afterward, and only a hash is stored server-side. If you lose it, revoke it and create a new one.

Key format

Keys are prefixed by environment so you can tell at a glance which one you're looking at:

Environment	Prefix	Use for
Live	eri_live_...	Real traffic, counts against your plan's quota
Test	eri_test_...	Confirming a new integration authenticates and parses correctly — see the restriction below

Test-mode keys can only check the email address you signed up with — they return a real, complete response for that one address, which is enough to verify your integration end-to-end, but they can't be used to check arbitrary addresses. Use a live key for that.

Making authenticated requests

curl https://api.emailriskradar.com/v1/email/check \
  -H "Authorization: Bearer eri_live_..." \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com"}'

Send the key in a standard Authorization: Bearer header — not as a query parameter, and not in the request body. Query parameters and bodies both risk ending up in server logs or browser history.

Authentication errors

error.code	HTTP status	Cause
AUTHENTICATION_REQUIRED	401	Missing or malformed Authorization header
INVALID_API_KEY	401	The key doesn't match any known key, or the credential presented isn't recognized
API_KEY_REVOKED	401	The key was valid but has since been revoked
TEST_KEY_EMAIL_RESTRICTED	403	A test-mode key checked an address other than your account's signup email

Keeping keys safe

Store keys in environment variables, never in source code or client-side bundles
Never call the API directly from a browser — a key embedded in frontend code is visible to anyone who opens dev tools
Use a live key for local development and CI against varied test addresses — test-environment keys are restricted to your own signup email, so they only prove a key authenticates, not general integration behavior
Revoke a key immediately if it's ever exposed (committed to a public repo, logged accidentally, etc.) and issue a new one

Webhook management uses a different auth model

Creating, listing, and deleting webhook endpoints is done through the dashboard (a logged-in session), not with an API key — there's currently no way to manage webhook endpoints using a bearer API key request. Once a webhook is registered, deliveries to your endpoint are authenticated separately, via an HMAC signature in the X-Webhook-Signature header — see the webhook section of the Endpoints Reference.