Connecting a REST API log source
Declare a codeless HTTP polling connector — endpoint, auth, pagination, a JSON path to the record array — and the platform polls it and normalises every record with no code shipped.
Every other log source in Connecting your first log source is either a push source with a fixed shape, or a pull source whose poller is Go code shipped by us, one file per vendor. A REST connector is a third option: you declare the poller yourself — the URL, how it authenticates, how it pages through results, and where in the JSON response the records live — and a background worker polls it on the schedule you set, with nothing built or deployed on our side.
What this is for
Use it for a vendor with a REST API and no dedicated connector in the catalogue: an internal tool, a smaller SaaS product, or a vendor whose logs only reach you through their own HTTP API rather than syslog or a bulk export. If a first-class connector already exists for the vendor you have in mind — GuardDuty, Defender for Cloud, Wazuh, Mimecast, Proofpoint and the rest of the connector catalogue — use that instead; a REST connector is the general-purpose fallback, not a replacement for a purpose-built one, and it has no vendor-specific knowledge of severity, entity types or incident shape the way those do.
Creating one in the console
SIEM → REST connectors (/siem/rest-connectors). The list shows every connector your organisation has configured, its auth kind, its pagination strategy, whether it is enabled, and when it last polled. Create opens a form asking for:
- Name and source label
- A name for the row, and a source label stamped onto every event this connector produces, so searches and rules can scope to just this connector's traffic.
- URL template
- The request URL.
{{cursor}},{{page}},{{offset}}and{{since}}(the RFC3339 timestamp of the last successful poll's newest record, or the zero time on the first poll) are substituted at request time, so a template likehttps://api.example.com/events?since={{since}}becomes an incremental poll with no extra configuration. - Records path
- A JSON path into the response body naming the array of records — for example
data.items, or left blank if the response body is itself the array. This is the one field genuinely required beyond the URL and source label. - Timestamp field
- A JSON path evaluated against each record, naming the event's own time. RFC3339 and Unix seconds/milliseconds are both recognised. Left blank, the time the platform received the record is used instead.
- Auth kind
- None, a bearer token, HTTP Basic, an API key in a named header, or OAuth2 client-credentials. Whichever needs a secret gets one password-masked field; the secret is sealed with the same envelope encryption the platform's other stored credentials use and is never shown again once saved — only a last-4-characters hint.
- Pagination
- None, a cursor token the response carries for the next request, a 1-based page number, a row offset, or a full "next link" URL the response hands you. Cursor and next-link kinds additionally need a JSON path to where that token or link appears in the response.
- Interval
- How often the connector polls, in seconds. Defaults to 300 (five minutes).
Test sends one poll immediately and reports how many records it found without saving anything to your event store — the response names the field keys it discovered, not the record contents themselves, so testing a connector against sensitive data does not put that data anywhere it would not otherwise go. Delete removes the connector outright; there is no disable-and-keep-history middle state beyond the existing enable/disable toggle on each row.
Limits worth knowing before you configure one
- Up to 200 pages per poll, so a misconfigured cursor or next-link loop — or a hostile API — cannot pin a worker indefinitely.
- Up to 50,000 records per poll, generous enough for a real catch-up after downtime without risking an unbounded ingest.
- 32 MiB response size per page, read with a hard limit rather than buffered without one.
What to read next
- Connecting your first log source — the concepts a REST connector shares with every other source, and the honest per-source status table.
- How your logs are normalised — the common event schema a REST connector's records land in, and what generic field capture does and does not give you.
- The connector catalogue — check here first for a purpose-built connector before reaching for this general-purpose one.