Set up OpenTelemetry with Authdog

Your app already emits OpenTelemetry traces, logs, and metrics. Until now those signals had to land in a collector you operated. Authdog now accepts the same OTLP/HTTP JSON export that SDKs, the OpenTelemetry Collector, and Grafana Alloy already know how to send.

This is the setup note behind the September 10 changelog entry.

What Authdog accepts

Three signals, on two equivalent bases:

Pick one base. Do not append /v1/traces to the endpoint yourself — exporters add that path.

Self-hosted deployments use your API origin in place of api.authdog.com. The OpenAPI document at /v1/openapi lists the same operations.

This path is for application telemetry. It is not the Authdog audit or security-event stream. Those still go through Events and webhooks and SIEM channels.

Create an environment API secret

The exporter authenticates with an environment API secret (adenv_…), the same credential family used by AuthZEN, FGA, and Vault. The secret identifies the tenant and environment. No tenant or environment id appears in the path.

In the console, select the project and environment, then Vault > API Keys (/dashboard/secrets?tab=api):

1. Choose Add new.
2. Copy the value once. It is not shown again.
3. Store it in your secret manager or the process environment of the exporter. Never ship it to a browser or mobile client.

A dev secret cannot write into prod. Mint one secret per environment you export into.

Any valid secret for that environment is enough. Ingest does not require environment:update.

Point the exporter

Set the standard OpenTelemetry environment variables on the process that already instruments your app:

OTEL_EXPORTER_OTLP_ENDPOINT=https://api.authdog.com
OTEL_EXPORTER_OTLP_PROTOCOL=http/json
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer adenv_…

http/json is required. Many SDKs default to protobuf. Authdog returns 415 for application/x-protobuf and gRPC with an OTLP partialSuccess message that tells you to switch protocol.

The OpenTelemetry Collector (and Alloy) use the same contract:

exporters:
  otlphttp/authdog:
    endpoint: https://api.authdog.com
    encoding: json
    headers:
      Authorization: Bearer ${AUTHDOG_ENV_API_SECRET}

service:
  pipelines:
    traces:
      exporters: [otlphttp/authdog]
    logs:
      exporters: [otlphttp/authdog]
    metrics:
      exporters: [otlphttp/authdog]

Keep the secret in the collector's environment, not in the config file you commit.

How the request is scoped

Authdog resolves tenant and environment from the Bearer secret. Resource attributes such as service.name and service.version travel with the payload so you can tell services apart. They are never used to choose the destination environment.

A secret minted in one environment cannot write into another, even if you set tenant.id or deployment.environment on the resource.

Empty {} and HTTP 200 means the export was fully accepted. That empty object is the OTLP success body, not a missing response.

If some records cannot be accepted, the response is still JSON:

{
  "partialSuccess": {
    "rejectedSpans": 12,
    "errorMessage": "accepted first 500 records; 12 dropped"
  }
}

Logs use rejectedLogRecords. Metrics use rejectedDataPoints.

Limits that affect the exporter

• Request body at most 2 MiB. Larger bodies return 413.
• At most 500 spans, log records, or data points per request. Overflow is reported as partialSuccess.
• Missing or invalid Authorization returns 401.

Batch and export intervals in your SDK or collector should stay inside those bounds. If a single flush is larger than 500 records, split it or lower the batch size.

Trust boundaries

The environment secret is a write credential for that environment's telemetry. Anyone who holds it can export traces, logs, and metrics into that environment. Treat it like a Vault or AuthZEN secret: server-side only, rotate by revoking the key in Vault > API Keys and minting a replacement.

Authdog does not authenticate end users on this path. Do not put user access tokens in OTEL_EXPORTER_OTLP_HEADERS.

This receiver does not replace Lidar or audit. Application spans are not security detections. Security events still use the dedicated event ingest and notification channels.

Verify the setup

1. Export a small traces payload against a non-production environment.
2. A successful call returns HTTP 200 and {}.
3. Drop the Authorization header and confirm 401.
4. Send Content-Type: application/x-protobuf and confirm 415.

A minimal traces check:

curl -sS -X POST https://api.authdog.com/v1/traces \
  -H "Authorization: Bearer $AUTHDOG_ENV_API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"resourceSpans":[]}'

Then point your existing SDK or collector at the same origin with http/json and the same secret.

OpenAPI: api.authdog.com/v1/openapi. Secret management: Vault. The original ship note is in the changelog.