Stream logs to a SIEM
Agent Handler exposes two cursor-paginated, pull-based log endpoints so your SIEM or observability platform can retrieve logs on a schedule, without you building a bespoke integration:
- Tool Call logs —
GET /api/v1/logs/tool-calls/(see Tool Call Logs) - API Request logs —
GET /api/v1/logs/api-calls/(see API Request Logs)
Full request/response schemas are in the API reference.
The log endpoints are an Enterprise feature. If they’re not enabled for your organization, the endpoints return 403. Contact your account team to enable them.
How the endpoints work
Both endpoints behave identically:
A poll loop looks like this:
Native pull vs. forwarder
Platforms fall into two camps:
- Native pull — the platform has a built-in REST/API poller that follows cursor pagination for you. Just configure it. Microsoft Sentinel, Elastic, Cribl Stream, and Sumo Logic are in this camp.
- Forwarder — the platform is push-only (it expects you to send logs to its intake), so you run a small scheduled job that walks the cursor loop above and posts batches to the platform. Datadog and Splunk are most reliably integrated this way.
Either way, the source side is identical: page through the endpoint with cursor, persist next_cursor, stop on has_more: false.
Platform setup
Datadog
Splunk
Microsoft Sentinel
Elastic
Cribl Stream
Sumo Logic
Other platforms
Forwarder. Datadog log collection is push-based — there’s no native input that follows cursor pagination against an arbitrary REST API. Run a scheduled job (Lambda, container, cron, or a Datadog Agent custom check) that pulls from the endpoint and POSTs to the Datadog Logs intake API.
- Create a Datadog API key (Organization Settings → API Keys). This is the
DD-API-KEYheader value — an API key, not an application key. - Pick the intake host for your Datadog site (mismatched site is the most common failure):
- US1 —
https://http-intake.logs.datadoghq.com - US3 —
https://http-intake.logs.us3.datadoghq.com - US5 —
https://http-intake.logs.us5.datadoghq.com - EU1 —
https://http-intake.logs.datadoghq.eu - AP1 —
https://http-intake.logs.ap1.datadoghq.com
- US1 —
- Store the Agent Handler
PRODUCTION_KEYand the Datadog API key in a secret manager, and persist the cursor in durable storage (DynamoDB, SSM, Redis, a DB row). - Implement the pull→push loop and schedule it (e.g. every 1–5 minutes). Persist
next_cursorafter a page ships successfully so a crash re-ships at most one page.
Gotchas
- The intake auth header is
DD-API-KEYwith an API key — notAuthorization: Bearer. The Bearer token is only for the Agent Handler side. - A single log is capped at ~1 MB (≤ 25 KB recommended). Chunk batches conservatively.
- Datadog intake doesn’t dedup. Persist the cursor only after a successful POST, and index a stable record ID so you can dedup downstream if a retry re-sends a page.
- Set each log’s
timestamp(epoch ms) from the record’s created time, or logs land at receive-time and look mis-ordered. - Don’t use the Observability Pipelines HTTP/S Client source — it polls a fixed URL and can’t carry a cursor.
Docs: Send logs (HTTP intake) & sites · Log collection · Agent custom check send_log