Skip to main content

API basics

Authentication

Every request to the Core API carries your Client Account's API Key in the X-API-Key header. There is no token exchange and no session: the key is the credential.
Header
X-API-Key
Key format
eri_…
Default expiry
90 days
Errors
401 · 403

Send the key​

Add the header to every request. The base URLs page lists the value for CORE_API_BASE_URL.

curl "$CORE_API_BASE_URL/reports" \
-H "X-API-Key: $ERI_API_KEY"

API Key format​

A key is one string of three parts joined by underscores, 85 characters in total:

eri_<public id>_<secret>
PartLengthPurpose
eri3 charactersFixed prefix that marks an ERI key
public id16 lowercase hex charactersIdentifies the key
secret64 lowercase hex charactersThe credential itself

Send the whole string, prefix included. Anywhere else ERI shows a key, it is masked to its last four characters, for example eri_****3f9a.

Get a key​

ERI support issues API Keys. Each key belongs to one Client Account and carries that account's content-access tier.

  • One active key per Client Account. During a rotation the outgoing key keeps working next to its replacement for a short overlap window.
  • Delivered once, by email. The full key goes to your Client Account's contact and is not shown again. Store it in your secrets manager straight away.
  • Expires 90 days after it is issued.
  • The tier sets what the key can read and how often. Standard reads the last 30 days of reports, Enterprise the full archive. Each tier also has a daily request limit.

Rotate or revoke a key​

Rotate a key by asking ERI support. The replacement has the same tier and arrives by email. The old key keeps working for 7 more days, then stops: switch your configuration to the new key inside that window.

Revoke a key by asking ERI support, for example when it may have leaked. A revoked key stops authenticating on its next request.

POST /api-keys/{id}/revoke exists too, but a Client Account's only key is the one making the call: it revokes itself, and every request after it, including a retry, gets 401.

Production: mutual TLS​

Production also requires an ERI-issued client certificate, presented during the TLS handshake (mutual TLS). The certificate secures the connection; the API Key still authenticates every request, so you need both. The "try it" console in the API reference cannot present the certificate, which is why it is set to Sandbox.

Authentication errors​

StatusCodeWhenWhat to do
401API_KEY_INVALIDThe header is missing, or the key is malformed, unknown, revoked or expiredCheck the key in your configuration. Don't retry with the same key
403REPORT_CONTENT_TIER_FORBIDDENThe key is valid, but the report predates your tier's archive depthSkip the report. Retrying won't change the answer

Every cause of a 401 returns the same body, on purpose: the response never reveals whether a key exists.

401 Unauthorized
{
"statusCode": 401,
"code": "API_KEY_INVALID",
"message": "Invalid or missing API key"
}

Send a correlation-id header of your own, or read the one the response carries when you don't, and quote it when you contact ERI support about a failed request.

Keep the key safe​

  • Call the API from your servers only. Never put the key in browser, mobile or desktop code, where anyone can read it.
  • Load it from an environment variable or a secrets manager, and keep it out of source control.
  • Keep it out of logs. Log the correlation-id instead.
  • If a key may have leaked, ask ERI support to revoke it, not rotate it: a rotated key keeps working for another 7 days.
  • Ask for a rotation at least 7 days before the key expires, so the overlap window fits and your integration never runs on an expired key.