/api/v1/apm prefix and require a bearer token.
streams.query. A platform caller can use
sys.telemetry.read in the protected _sys scope. Writing service definitions, error states,
service level objectives, and APM settings requires apm.manage. Reporting a deployment requires
apm.deploy.
Endpoints
Path parameters must be URL-encoded. Use the exact
transaction name or error fingerprint
returned by a list response.
Common query parameters
Filters must be non-empty and no longer than 192 bytes. The range cannot exceed the configured
maximum, which defaults to 30 days (
[apm].max_query_range_days).
Sort fields
/overview accepts the same filters and resolution but does not paginate. Detail, comparison, and
health endpoints do not return paginated lists.
Query an overview
red, trend, service_health, services, top_transactions,
top_dependencies, top_errors, and recent_versions, plus a common meta object, and:
Read insights
GET /api/v1/apm/insights takes the common range and filter parameters and answers meta and:
Each finding carries:
The thresholds are in Insights and investigations.
List and paginate services
items holds one entry per service:
next_cursor or previous_cursor unchanged with the same endpoint, filters, range, sort, and
direction. Cursors are signed and scoped to the original request context. Do not decode or edit a
cursor.
The traces object of an entry restates the service, version, transaction, dependency, and error filters, and the range of the entry, so that a client can open the matching traces.
Read RED metrics
Every summary carries ared object with the request, error, and duration figures of the range.
Service and transaction summaries carry
apdex_threshold_micros, the T their Apdex was read with.
A service summary also carries health and health_reasons: each figure past a line, as metric
(error_rate or p95), level, value, and threshold. It carries sparkline, the request count, error count, and p95 of each bucket,
and current_version with current_version_since, the version seen most recently and when it was
first seen. The detail of a service or a transaction carries latency_distribution: the histogram
buckets that hold requests, each as lower_micros, upper_micros, and count, narrowed to the
fastest and slowest request.
Keep service definitions
A definition records who owns a service and how much it matters. It is keyed bynamespace and the
service name, so it holds in every environment, and it can exist before the service reports.
A save keeps the definition’s
key_transactions, which change one at a time. The response is the
saved definition with namespace, name, key_transactions, updated_by, and updated_at.
DELETE answers 204, or 404 when the service has no definition.
Star key transactions
key: true adds the endpoint to key_transactions, false takes it out; asking for what is already
so changes nothing. A service without a definition gets one. A service keeps up to 50 key
transactions, and the overflow row __other__ cannot be one. The response is the definition after
the change.
Read a service’s coverage
GET /api/v1/apm/services/{service}/coverage takes namespace and environment, both required, and
optional to, the end of the range in view in microseconds (now by default). It looks over the day
before to, and keeps each answer for five minutes.
missing means the look found nothing. unknown means the look failed or took longer than three
seconds. rum is never missing: a sample of traces can show that sessions reach a service, not that
none do.
Read what a service runs as
GET /api/v1/apm/services and GET /api/v1/apm/services/{service} give each service summary a
profile, read from the instances that reported in the range, those of version alone when the
parameter is set. Each list is ranked by how many instances share a value, at most five, as
{ "value": "1.8.2", "instances": 4 }.
GET /api/v1/apm/services/{service}/instances lists the instances one by one, the most recently
seen first, at most 500. It takes namespace, environment, and optional version, from, and
to; without a service and an environment it answers 400. Each item has instance_id (the
service.instance.id, else k8s.pod.name, else host.name), version, first_seen_at,
last_seen_at, attributes, a map of the attributes the instance reported last, and what it served
in the range: red, as in summaries with Apdex at the service’s threshold, and sparkline. Past the
instance limit the rest are counted in one item whose instance_id is __other__. An instance that
served in the range before anything was kept about it is listed with empty attributes.
Set an error group’s state
status is open, investigating, resolved, or ignored. assignee_id is a member of the
organization or null, and team_id a team of the organization or null. last_seen_at, optional, is when the reader last saw the group, in microseconds. Setting
resolved records the time as resolved_at.
Error summaries carry the state as issue, or null while nobody has set one. issue.regressed
is true when a resolved group occurred again after resolved_at; the unresolved filter keeps
such groups. Setting the state of a fingerprint the projection does not know answers 404.
Keep service level objectives
A service level objective (SLO) promises a share of good requests of a service in one environment, or of one of its endpoints, over a rolling window. See Service level objectives for what each figure means.POST and PUT answer the saved SLO with id, created_by, created_at, updated_by, and
updated_at. GET /api/v1/apm/slos answers every SLO of the organization as a status. Pass
namespace, service, and environment together to keep the SLOs of one service. The window ends
at the time of the call, so the common range parameters do not apply.
GET /api/v1/apm/slos/{id} answers status and history, one entry for each UTC day of the window
with requests, the oldest first. Each entry has day_start in microseconds, sli, good_requests,
and total_requests.
DELETE answers 204. It answers 409 while alert rules watch the SLO, such as its burn-rate
alerts: delete those rules first. Alert rules on an SLO are APM rules with the metric
slo_burn_rate. See Create a rule.
Disambiguate a transaction
Two transaction kinds can share a name. Pass the optionalkind parameter to select one:
http, rpc, messaging, span, and other. A name that several
services or kinds share answers 400 with APM transaction identity is ambiguous; provide service, namespace, environment, and kind.
Compare versions
Supply differentbaseline and candidate values. Add a service filter to compare one service.
baseline and candidate sides, each with version, sample_count, and
red, plus a delta, a status, regressed_transactions, and regressed_errors. Each regression
list holds at most 20 entries.
A missing
candidate or baseline, or two identical versions, answer 400.
Read a service’s versions
GET /api/v1/apm/services/{service} answers versions, the versions seen in the range. Each carries
red, what it served in the range, and verdict, how it did against the version of the same service
first seen before it, judged as a comparison is:
The first version seen has no
verdict. A version filter on the request does not narrow the
figures: every version is read from the whole service.
Read where errors happened
GET /api/v1/apm/errors answers a breakdown beside the page, over every group the status filter
keeps (not only the page’s), and GET /api/v1/apm/errors/{fingerprint} answers the breakdown of
the group. It holds versions, environments, and languages, each a list of value and count,
the occurrences, largest first. A value is empty when the spans did not report it; after the first
seven values the rest count together as __other__. The language is the service’s
telemetry.sdk.language.
Keep error grouping rules
A rule groups errors otherwise than by their type, frame, and endpoint when they are seen. Rules are tried inposition order and the first that matches holds.
The response is the rule with its
id, position, updated_by, and updated_at. An organization
keeps at most 100 rules. PUT /api/v1/apm/error-rules/order takes {"ids": [...]}, puts those rules
first in that order and the others after them, and answers the rules in their new order.
A change applies at once on the node that saves it and within 30 seconds on the others, to the
errors seen from then on; groups already made stay as they are.
Read the service map
GET /api/v1/apm/map takes the common range, environment, and namespace parameters and answers
nodes, edges, namespaces (of the services in the environment), environments (every one), and
truncated (true when only the 400 busiest nodes are kept).
Calls between services come from the service graph, with the P95 of their slowest minute; the rest
from the APM buckets.
GET /api/v1/apm/map/edge takes source and target node ids besides the same
parameters and answers kind, red, trend, operations (name, kind, red), every_caller
(true when the operations are the called service’s endpoints from every caller), and errors, the
called service’s error groups.
Read a service’s blast radius
GET /api/v1/apm/blast-radius takes service, which it requires, and the common range and
environment parameters. It reads the whole map of the environment, whatever the namespace, and
answers meta, service (the service’s own node, absent when the map has it nowhere in the range),
upstream (what calls it, up to three hops), and downstream (what it calls or publishes to, up to two
hops). Each side holds at most 30 nodes, the unhealthy first; calls gone against the stretch before are
left out.
Report and list deployments
POST /api/v1/apm/deployments takes the deployment as JSON and answers 201 with it, its id,
created_by, and created_at added. The fields, their limits, and CI examples are in
Deployments. The service and the environment
are named as the organization’s naming rules, environment mapping, and aliases read them. A
repository address is kept with its password masked. A configuration change or a feature flag sets
kind to configuration or feature_flag and needs no version.
GET /api/v1/apm/deployments takes service, namespace, environment, from, and to, the
range in microseconds, and answers at most 200 deployments, the newest first. A deployment reported
without a namespace or an environment is listed for every one.
Keep APM settings
GET /api/v1/apm/settings answers the organization’s settings; PUT replaces them as a whole and
answers what was kept:
default. The
limits and what each setting does are in APM settings. A save applies at once
on the node that saves it and within 30 seconds on the others.
The platform’s cardinality limits are read and replaced with GET and PUT /api/v1/settings/apm_limits, which require sys.settings.manage. The body carries
services_per_org_hour, transactions_per_service_hour, dependencies_per_service_hour,
operations_per_dependency_hour, error_groups_per_service_hour, versions_per_service_hour, and
instances_per_service_hour, each from 1 to 100000.
Check projection health
GET /api/v1/apm/health reports whether the projection runs and whether it is healthy.
degraded is true when the projector or the rollup reports a problem, and last_error explains it. Growing queue_drops, flush_failures, or cardinality_rejections explain gaps in the data.
Read response metadata
Every endpoint returns a commonmeta object:
- Treat
activation_boundary: trueas incomplete coverage beforeprojection_started_at. - Treat
data_quality.partial: trueas incomplete data, not as a complete zero. - Inspect
gapsfor queue, repository, flush, late-data, cardinality, or shutdown failures. - Use
last_complete_bucket_atto determine whether recent data is still being finalized. - Inspect
overflow_dimensionsbefore relying on a high-cardinality breakdown.
Errors
APM guide
Instrument services and investigate performance in the UI.
Trace intake
Send OpenTelemetry traces that feed APM.