Why keys, not a shared secret
The HTTP and HEC listeners accept a deployment-wide shared key, and everything sent with it lands in the default organization. That is fine for a single-company deployment and wrong for a provider. Ingest keys solve it: each key belongs to one organization, and events sent with it are stamped with that organization on the server. The sender never chooses a tenant.
Creating a key
Settings › Integrations › Ingest keys › Create. Pick the organization, give the key a name (the sender it is for), and copy the value. The value is shown once and stored hashed; if you lose it, create a new key and revoke the old one.
Using a key
Send events to the console's ingest endpoint with the key as a bearer token:
curl -X POST https://console.xdr.example.com/api/ingest/v1/events \
-H "Authorization: Bearer xk_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '[{"@timestamp":"2026-09-15T09:31:02Z","event":{"module":"custom","type":"info"},"message":"hello"}]'
The body is an object or an array of objects. Events go through the same normalisation as every other input.
Revoking and rotating
Revoke a key from the same page. Revocation is immediate and audited. To rotate, create the new key, switch the sender, then revoke the old one.
Keys and the agent
Endpoint agents enrol with a token and authenticate with their own credential. Ingest keys are for HTTP and HEC senders.