Datadog is the largest observability profile in the catalog at 85 distinct APIs. That puts it in the same neighborhood as the card networks for sheer breadth — and the comparison is apt. A modern observability platform isn’t one product anymore. It’s a federated surface of telemetry types, control-plane services, and operational integrations, and Datadog’s API portfolio reflects that.
The shape of an 85-API observability platform
The 85 APIs partition naturally into a few functional zones:
- Telemetry ingest — Metrics, Logs, Events, Traces, Profiles, RUM, Synthetics. The raw-data write surface. Each telemetry type has its own API because each has its own schema, partitioning, and retention semantics.
- Telemetry query — Metrics queries, log search, event search, span search, scalar/timeseries computation. Read-side counterparts to each ingest API.
- Alerting and monitoring — Monitors, Notebooks, Service Level Objectives, Downtimes, Notification Rules. The “what should page somebody” surface.
- Incident management — Incidents API, Incident Teams, post-mortem workflows. The “something is on fire” surface.
- Configuration management — Dashboards, Hosts, Tags, Service Catalog, Software Catalog, Pipelines. The “describe my infrastructure” surface.
- Security platform — Cloud SIEM, Cloud Security Management, Sensitive Data Scanner, ASM. Datadog’s expansion into the security analytics adjacency.
- Account and governance — Users, Roles, Permissions, API Keys, Audit Trail, Restriction Policies. The control-plane surface.
Eighty-five APIs is a lot. It’s also a useful demonstration that observability platforms have become integration platforms. The APIs aren’t there because Datadog wants developers to write code against telemetry; they’re there because every modern company has an opinionated way it wants to push, query, slice, and govern its operational data — and the API is how Datadog meets that.
What’s interesting about the surface
A few specifics worth knowing:
- Each telemetry type has its own API. Some providers ship one big “send us your data” endpoint. Datadog ships separate Metrics, Logs, Events, Traces, Profiles, RUM, and Synthetics APIs. The catalog ingests them as discrete entries, which means an integration tool can target “I want to send logs only” without dragging in the full telemetry surface.
- The Service Catalog API is itself a catalog. Datadog’s Service Catalog is a federated index of services across an organization — which is a catalog-of-catalogs pattern. apis.io indexes Datadog’s surface; Datadog’s Service Catalog indexes a customer’s internal service inventory. Same shape, different scope.
- Audit Trail is a first-class API. Not a setting, not an export. An API. That’s the right shape if you’re building a compliance-aware integration on top of Datadog — your auditors want the audit trail to be programmatically queryable.
- Incidents, Notebooks, and Restriction Policies are all separate. The decomposition between “operate”, “document”, and “govern” is reflected in distinct API surfaces. It’s a useful design pattern worth borrowing.
The catalog angle
For an apis.io user, the value of profiling a surface this big isn’t memorising the 85 APIs. It’s:
- Knowing that the Datadog surface is 85 APIs and not 1, so you scope your project accordingly.
- Using the capability index at capabilities.apis.io to find the specific telemetry verb you need rather than scrolling through Datadog’s docs sidebar.
- Comparing the shape against other observability providers in the catalog — Grafana, Honeycomb, New Relic, Sentry — to see where each is partitioned similarly and where each is consolidated.
The takeaway
If you’re building against Datadog, providers.apis.io/providers/datadog is a cleaner index of the 85 APIs than Datadog’s own docs navigation. If you’re publishing an observability platform of your own, the per-telemetry-type partitioning is the pattern that holds up at scale — and the surface separation between operate / document / govern is worth borrowing.
Eighty-five APIs is not bloat. It’s the natural shape of a federated observability platform that takes its own data-model partitioning seriously.