Understanding the response

What this page covers: the envelope every v2 response uses, and the shape of the data inside it. Responses are always JSON.

The JSend envelope

Every response is wrapped in JSend. The status field tells you which of three shapes you're looking at:

{
  "status": "success",
  "data": [ { "...": "..." } ]
}

{
  "status": "fail",
  "data": { "entityId": "Server could not be found." }
}

{
  "status": "error",
  "message": "The requested range is not valid. Please request a range between 15 minutes and 31 days."
}

The HTTP status code carries the primary signal (check it first). The body's status field mirrors that: 2xx maps to success, most 4xx maps to fail, and 401/403/416/5xx map to error.

Not every response has a JSend body. Some responses, including 429 (rate limited) and a routing-level 404 (v2 turned off, or an endpoint not enabled), come back with no envelope at all, so always branch on the HTTP status code, not the body.

The data shape

Resources come back in one of two shapes:

• Flat objects - for example, a monitored server. No time-series data attached.
• Series - for example, a metric series. Each entry pairs a metric with an entity and carries a dataPoints array of {timestamp, value} samples.

List endpoints always return an array in data, even when there's only one result or none at all (an empty array, not null).

Sample resolution

Time-series responses don't include every raw sample. The API returns the same points the Redgate Monitor UI shows for the range you ask for. The point interval depends on the time range you request, so keep it consistent if you're combining series.

Nested entities

A metricSeries carries a parentEntity chain that walks up the hierarchy and always ends with a null parentEntity. Its depth depends on the entity type, for example a cluster has no parent, a SQL Server has one, a database has two, and a database file chains file, database, server, cluster. The JSON structure is the same across every metric type and every target type; only the depth of the chain varies.

Models

The objects inside data are documented as named models, for example MonitoredServer and MetricSeries. Each endpoint reference page names the model it returns, and every model is described in full (its fields, types, and allowed values) on the Models page.

Dates

Every date and time in the API is ISO 8601, in both requests and responses, for example 2026-08-19T12:00:00Z.

Common pitfalls

• Checking the body's status field without checking the HTTP status code first. They carry the same signal, but the HTTP code is the one to branch your error handling on.
• Assuming fail and error bodies look the same. fail gives you a field-to-message map; error gives you a plain message string. Parse accordingly.

Next steps

Jump to Monitored servers to make a real call.