Datadog APM Service Level Objectives API

[Service Level Objectives](https://docs.datadoghq.com/monitors/service_level_objectives/#configuration) (or SLOs) are a key part of the site reliability engineering toolkit. SLOs provide a framework for defining clear targets around application performance, which ultimately help teams provide a consistent customer experience, balance feature development with platform stability, and improve communication with internal and external users.

Business capability
Service Reliability Engineering BC-4220.10

Operations 10

Each operation below carries the questions people ask an LLM about it and the instructions they give an agent to run it. Generated by API Evangelist overlay

GET /api/v1/slo List SLOs with filters · Get all SLOs #
Ask an LLM
“Which SLOs in our org carry a particular tag?”
“Can I list only the SLOs that have been deleted?”
Tell an agent
List all SLOs tagged {tags_query}.
Get the SLOs with IDs {ids}.
POST /api/v1/slo Create a service level objective · Create an SLO object #
Ask an LLM
“How do I set up a 99.9% availability SLO over 30 days?”
“Can I create a monitor-based SLO from a list of monitor IDs?”
Tell an agent
Create a {type} SLO named {name} with thresholds {thresholds}.
Create a monitor SLO called {name} over monitors {monitor_ids} with thresholds {thresholds}.
POST /api/v1/slo/bulk_delete Bulk delete SLO thresholds by timeframe · Bulk Delete SLO Timeframes #
Ask an LLM
“Can I drop just the 7-day threshold from several SLOs at once?”
“What happens to an SLO when I bulk delete all of its timeframes?”
Tell an agent destructive · confirm first
Bulk delete the 7d timeframe from these SLOs in one call.
Remove the listed threshold timeframes across multiple SLOs at once.
GET /api/v1/slo/can_delete Check whether SLOs can be safely deleted · Check if SLOs can be safely deleted #
Ask an LLM
“Is an SLO still used on a dashboard before I delete it?”
“Can I check several SLOs for dependencies before removing them?”
Tell an agent
Check whether SLOs {ids} can be safely deleted.
Verify nothing references SLO {ids} before I remove it.
GET /api/v1/slo/search Search SLOs with facets · Search for SLOs #
Ask an LLM
“Which SLOs belong to a given service or team when I search by query syntax?”
“Can an SLO search also return facet counts?”
Tell an agent
Search SLOs for {query}.
Search SLOs matching {query} with include_facets set to {include_facets}.
DELETE /api/v1/slo/{slo_id} Delete an SLO · Delete an SLO #
Ask an LLM
“Why does deleting an SLO return a conflict when it's on a dashboard?”
“Can I force delete an SLO that other resources still reference?”
Tell an agent destructive · confirm first
Delete SLO {slo_id}.
Force delete SLO {slo_id} even though it's referenced elsewhere, with force set to {force}.
GET /api/v1/slo/{slo_id} Get an SLO's details · Get an SLO's details #
Ask an LLM
“What target and timeframe is a specific SLO configured with?”
“Which monitors alert on a given SLO?”
Tell an agent
Get the details of SLO {slo_id}.
Show SLO {slo_id} along with the monitor alerts that reference it, setting that flag to {with_alerts}.
PUT /api/v1/slo/{slo_id} Update an existing SLO · Update an SLO #
Ask an LLM
“How do I raise the target on an SLO I already have?”
“Can I change the tags or description of an existing SLO?”
Tell an agent
Update SLO {slo_id} to use thresholds {thresholds}.
Rename existing SLO {slo_id} to {name}, keeping type {type} and thresholds {thresholds}.
GET /api/v1/slo/{slo_id}/history Get an SLO's history and error budget · Get an SLO's history #
Ask an LLM
“How much error budget does an SLO have left for last month?”
“Can I see an SLO's history without corrections applied?”
Tell an agent
Get the history of SLO {slo_id} from {from_ts} to {to_ts}.
Show SLO {slo_id} history between {from_ts} and {to_ts} with remaining error budget against target {target}.
GET /api/v1/slo/{slo_id}/corrections List corrections applied to one SLO · Get Corrections For an SLO #
Ask an LLM
“Which corrections have been applied to one particular SLO?”
“What downtime windows are excluded from a single SLO's calculation?”
Tell an agent
List the corrections applied to SLO {slo_id}.
Show every correction attached to SLO {slo_id}.

Work with this as data

Every API here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for apis

7 MCP tools reach this
  • find_apisBrowse and filter every API in the catalog.
  • get_api_artifactsOne API's artifacts, grouped by type.
  • get_openapiThe primary OpenAPI for this API.
  • find_similar_apisAPIs that look like this one.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This API
curl "https://apis.io/api/v1/apis/datadog-apm:datadog-apm-service-level-objectives-api"
All apis
curl "https://apis.io/api/v1/apis?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.

OpenAPI Specification

datadog-apm-service-level-objectives-api-openapi.yml Raw ↑
openapi: 3.2.0
info:
  title: Datadog APM — (API v1) Service Level Objectives API
  description: The Service Level Objective surface of the Datadog API v1, extracted verbatim from the OpenAPI definition Datadog publishes for its own API clients.
  version: '1.0'
  contact:
    email: support@datadoghq.com
    name: Datadog Support
    url: https://www.datadoghq.com/support/
  x-source: https://raw.githubusercontent.com/DataDog/datadog-api-client-go/master/.generator/schemas/v1/openapi.yaml
  x-extracted: '2026-09-05'
  x-extraction-note: Path items, components and security schemes copied VERBATIM from the Datadog-published OpenAPI at x-source; only the APM-relevant subset of paths is retained. No content was authored by API Evangelist.
servers:
- url: https://{subdomain}.{site}
  variables:
    site:
      default: datadoghq.com
      description: The regional site for Datadog customers.
      enum:
      - datadoghq.com
      - us3.datadoghq.com
      - us5.datadoghq.com
      - ap1.datadoghq.com
      - ap2.datadoghq.com
      - uk1.datadoghq.com
      - datadoghq.eu
      - ddog-gov.com
      - us2.ddog-gov.com
      - uk1.datadoghq.com
    subdomain:
      default: api
      description: The subdomain where the API is deployed.
- url: '{protocol}://{name}'
  variables:
    name:
      default: api.datadoghq.com
      description: Full site DNS name.
    protocol:
      default: https
      description: The protocol for accessing the API.
- url: https://{subdomain}.{site}
  variables:
    site:
      default: datadoghq.com
      description: Any Datadog deployment.
    subdomain:
      default: api
      description: The subdomain where the API is deployed.
security:
- apiKeyAuth: []
  appKeyAuth: []
tags:


# --- truncated at 32 KB (102 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/datadog-apm/refs/heads/main/openapi/datadog-apm-service-level-objectives-api-openapi.yml