Datadog OTLP Intake Endpoint

Docs > OpenTelemetry in Datadog > Send OpenTelemetry Data to Datadog > Datadog OTLP Intake Endpoint

Overview

For production workloads, Datadog recommends sending OpenTelemetry data through a Datadog Agent or OpenTelemetry Collector with the Datadog Exporter. These components provide metadata enrichment, signal normalization, and centralized sampling.

You can also send data from an OpenTelemetry Collector without Datadog-specific components. This experience is in Preview.

Use the direct OTLP intake endpoints on this page when deploying a Collector or Agent is not feasible. Examples include serverless functions, managed platforms that export telemetry on your behalf, and environments with strict resource constraints.

Diagram: OpenTelemetry SDK sends data directly to Datadog through the intake endpoint.

Host metadata sent to this endpoint does not populate the Infrastructure Host List.

Your setup depends on where your telemetry is coming from. Check the Managed platforms list first; if your platform has a dedicated endpoint, use it. Otherwise, use the serverless or signal-specific pages.

If your telemetry comes from…	Start here
A managed platform (Cloudflare, Vercel, Heroku, Netlify, Modal, and others)	Managed platforms
A serverless environment sending traces (Lambda, ECS Fargate, Azure Functions, Cloud Run, GKE Autopilot)	Serverless
Your own app, host, or container	Logs, Metrics, or Traces

Intake limits

Datadog enforces a maximum payload size per request on each OTLP intake endpoint. Requests that exceed the limit are rejected with an HTTP 413 Request Entity Too Large response. If you receive a 413, reduce the export batch size or flush more frequently so each request stays under the limit.