Datadog

Overview

Datadog ingests custom log data over a plain HTTPS endpoint — the Logs Intake API. Britive can push its audit log to any HTTPS URL through a webhook notification medium. Pointing one at the other gives you a live feed of Britive audit activity in Datadog with nothing to install and no compute to run on either side.

What you’ll accomplish:

• Get a Datadog API key and the correct Logs Intake API endpoint for your Datadog site
• Confirm the endpoint accepts a test log
• Configure a webhook notification medium in Britive pointed at it
• Attach the notification medium to Britive’s audit log so matching events are forwarded automatically

Prerequisites

Before you begin, make sure you have:

• A Britive tenant with System admin access (to configure notification mediums and audit log webhooks)
• A Datadog organization, and you know which Datadog site it’s on (US1, US3, US5, EU1, AP1, AP2, UK1, US1-FED, or US2-FED) — every request in this guide goes to a site-specific hostname
• Permission to create an API key under Datadog Organization Settings

How It Works

    graph LR
    A["Britive Audit Log"] -->|"event matches<br/>filter expression"| B["Webhook<br/>Notification Medium"]
    B -->|"HTTPS POST<br/>(API key on the request)"| C["Datadog<br/>Logs Intake API v2"]
    C --> D["Log indexed<br/>under ddsource / service"]
  

Unlike a SIEM that requires you to provision a separate feed object first, Datadog’s Logs Intake API is a fixed, always-on endpoint per site — there’s no “create a feed” step. You only need a valid API key and the right hostname for your org’s Datadog site.

Get a Datadog API Key and Intake Endpoint

Test the Intake Endpoint

Britive’s own integration doc gives this as the verification command before wiring anything up:

curl -X POST -H 'Content-Type: application/json' \
  -d '{"test": "test"}' \
  'https://http-intake.logs.us5.datadoghq.com/api/v2/logs?dd-api-key=<apikey>&ddsource=demo&service=br'

Replace us5 with your own site’s hostname from the table above, <apikey> with the key you just created, and set ddsource/service to values meaningful in your environment.

A successful request returns HTTP 202 and an empty body. Check the status code explicitly, since curl without -f/--fail prints nothing distinctive on success either way:

curl -s -o /dev/null -w '%{http_code}\n' -X POST -H 'Content-Type: application/json' \
  -d '{"test": "test"}' \
  'https://http-intake.logs.us5.datadoghq.com/api/v2/logs?dd-api-key=<apikey>&ddsource=demo&service=br'

Datadog’s limits on this endpoint, per request:

Once this command reliably returns 202, you’re ready to build the notification medium URL in Britive.

Configure the Webhook Notification Medium in Britive

https://http-intake.logs.<your-site-hostname>/api/v2/logs?dd-api-key=<apikey>&ddsource=britive&service=britive-audit-log

Forward Audit Logs to the Webhook

What Arrives in Datadog

Datadog does not require a parser the way some SIEMs do — it indexes whatever JSON keys a log contains and makes them searchable as facets. But Britive’s audit record doesn’t naturally populate Datadog’s own reserved attributes:

Britive’s audit record itself carries the same five top-level groups documented for the Audit Log and used throughout Recommended Alerts: actor, client, event, target, and result. Expect to find these as nested JSON facets under whatever the log body lands as in Datadog, rather than as Datadog’s own first-class fields — capture a real event and inspect it in Datadog’s Log Explorer before building dashboards or monitors, since the exact shape hasn’t been independently confirmed against a live payload for this guide.

If you want typed fields instead of raw JSON facets, add a Log Pipeline with a JSON parser processor scoped to source:britive (or whatever ddsource you chose).

Verify

Troubleshoot

Next Steps