Skip to main content
The Gateway Guardrail Metrics Query API provides a flexible way to query guardrail evaluations: which guardrail ran on which entity (input or output), what the outcome was (pass, fail, error), and how long it took. You can retrieve either distribution (aggregated) or timeseries results with powerful filtering and grouping.
This page covers datasource: "guardrailMetrics". For other datasources, see the sibling pages for Model, MCP, Cache, Routing, and Agent metrics.
All requests go to a single endpoint:
Send JSON with Authorization: Bearer <your_api_key> and Content-Type: application/json.

Access control

Access to metrics is governed by the data access rules configured by your tenant. The server applies these rules automatically based on the caller’s identity—you don’t pass any RBAC or scoping fields in the request. What a caller can query (their own data, their team’s data, or tenant-wide data) depends entirely on the rules an admin has set up. See Configure Data Access for how these rules are defined and evaluated.

Authentication

Authenticate with your TrueFoundry API key. You can use either a Personal Access Token (PAT) or Virtual Account Token (VAT).
  1. Personal Access Token (PAT): Go to Access → Personal Access Tokens in your TrueFoundry dashboard
  2. Virtual Account Token (VAT): Go to Access → Virtual Account Tokens (requires admin permissions)
For detailed authentication setup, see our Authentication guide.

Quick start

Counts and latency percentiles per guardrail and outcome, restricted to input-scope evaluations:

API reference

Post JSON to the endpoint above with Authorization: Bearer <your_api_key> and Content-Type: application/json.

Request parameters

string
required
ISO 8601 timestamp marking the inclusive lower bound of the query window.
string
required
ISO 8601 timestamp marking the exclusive upper bound of the query window.
string
required
The data source to query. Use "guardrailMetrics" for Gateway guardrail metrics.
string
required
The type of query to execute:
  • "distribution": returns aggregated rows (one row per groupBy combination).
  • "timeseries": returns time-bucketed rows. Requires interval.
array
Array of { type, column } objects describing the aggregations to compute. When omitted, only the implicit total = COUNT(*) is returned.
array
Array of field names to group results by. Custom metadata keys are supported with a metadata. prefix.
When groupBy contains userEmail (without virtualaccount), the server auto-injects WHERE CreatedBySubjectType = 'user'. virtualaccount alone auto-injects 'virtualaccount'. When both appear, scope it yourself with createdBySubjectType if needed.
array
Array of filter objects, AND-combined. See Filtering below for the full operator reference and the per-field allow-list.
string
Required for timeseries queries. Bucket size as <positive integer> <unit>, where <unit> is one of second, minute, hour, day, week, month, year (with or without a trailing s). Examples: "30 second", "5 minute", "1 hour", "1 day". Compound expressions like "1 hour 30 minute" are rejected.
number
deprecated
Deprecated alias for interval. Accepts a positive integer number of seconds. Prefer interval in new code. If both are provided, interval wins.

Filtering

Filters narrow down the rows that go into each aggregation and group. They are AND-combined; there is no OR-group support. The server enforces a per-field operator allow-list, so the exact subset of operators you can use depends on the field.
For standard datasource fields, use fieldName:
The guardrail-specific string fields (guardrailName, appliedOnEntityScope, guardrailResult) accept only a narrow set of string operators (IN, NOT_IN, STRING_CONTAINS, STRING_STARTS_WITH, STRING_ENDS_WITH). EQUAL and NOT_EQUAL are only supported on subject fields and conversationID.
String field operatorsNumeric field operatorsArray field operators (used by team)
Custom metadata filtering and grouping. Every datasource supports filtering and grouping by custom request-metadata keys:
  • Filter: { "metadataKey": "environment", "operator": "EQUAL", "value": "prod" }
  • Group: include "metadata.environment" in the groupBy array.
Metadata fields are treated as strings; use the string field operators above.Implicit team unnesting. When team is in groupBy (or used as the column of an aggregation), the server transparently UNNESTs the Teams array CTE before applying RBAC. Callers don’t need to do anything extra. Rows whose Teams array is NULL or empty drop out naturally.Combining multiple filters. Filters are AND-combined:

Query examples

Every example posts a JSON body to the endpoint above. To keep the snippets short, only the json body is shown; the request wrapper is identical to the Quick start.

Distribution examples

Counts grouped by guardrail and outcome, useful for spotting guardrails that fail most often:
p50, p90, and p99 grouped by guardrail, restricted to output-scope evaluations:
Volume and average latency of evaluations slower than 500 ms, grouped by guardrail:
Restrict to failed evaluations, grouped by guardrail and scope:
Counts by team and a custom metadata key, restricted via team array filter:
How many unique guardrails ran on input vs output:
Use IN on guardrailName to focus on a subset:

Timeseries examples

Every timeseries query must include interval (or the deprecated intervalInSeconds). Buckets are expressed as <positive integer> <unit> strings like "5 minute", "1 hour", or "1 day".
Total guardrail evaluations per hour:
Track p99 evaluation latency per scope (input / output) bucket-by-bucket:
Track per-guardrail failure rate over time:
Fine-grained breakdown to investigate a regression:
Daily evaluation volume per guardrail across a 7-day window:
Focus on a few guardrails of interest:
Per-team guardrail activity over time:

Response format

Every successful response has the same outer shape:
  • total: implicit COUNT(*) for the row. Always present.
  • <aggregationKey>: one key per requested aggregation. The key is <type><Column> in camelCase (e.g. countGuardrailName, p99LatencyMs).
  • <groupByKey>: one key per groupBy entry. The key is the lowerCamelCase form of the underlying column. Two special mappings:
    • userEmail and virtualaccount both map to createdBySubjectSlug in the response.
    • team maps to team (the value is a single unnested scalar, not an array). All other groupBy keys preserve their lowerCamelCase name.
  • startTimestamp: present only for timeseries responses. Bucket start as an ISO 8601 timestamp string (e.g. "2026-04-29T12:00:00.000Z"). Distribution responses omit it.
  • endTimestamp: present only for timeseries responses. Bucket end as an ISO 8601 timestamp string, equal to the next bucket’s startTimestamp (e.g. "2026-04-29T13:00:00.000Z"). Distribution responses omit it.
If groupBy is empty or omitted, the response collapses to a single row (or one row per timeseries bucket) summarising every guardrail evaluation inside the window.

Error responses

A malformed query returns 400 Bad Request:
Common causes of 400:
  • Operator not allowed on this field, for example, EQUAL on guardrailName (it supports only IN, NOT_IN, and STRING_* operators).
  • Missing required value (or wrong shape, e.g. scalar where array is expected for IN / BETWEEN).
  • Unknown field name for the datasource.
  • Invalid interval format (compound expressions, unrecognised unit, non-positive integer).
  • Missing required interval for a timeseries query.
Other status codes:
  • 401 Unauthorized: missing or invalid bearer token.
  • 403 Forbidden: caller does not have permission for the requested scope.
  • 500 Internal Server Error: unexpected server error while executing the query.