Response Mapping
Response mappings tell Rhesis how to extract platform variables from your API’s response. Each field is evaluated independently using JSONPath, Jinja2, or both.
JSONPath Expressions
Expressions starting with $ are evaluated as JSONPath against the response body:
Common patterns:
| Pattern | Description |
|---|---|
$.field | Top-level field |
$.nested.field | Nested field |
$.array[0].field | Field from first array element |
$.data[*].text | text field from all array elements |
Jinja2 with jsonpath()
For conditional logic or fallback values, wrap expressions in Jinja2:
Returns the first non-empty value. Pure JSONPath expressions (starting with $) work without any Jinja2 wrapping.
Mixing Approaches
Each field is evaluated independently — you can mix JSONPath and Jinja2 in the same mapping:
Platform-Managed Fields
output must always be mapped. Without it, Rhesis cannot evaluate responses against metrics.
Actively used by Rhesis:
output— main response text, used for metric evaluationcontext— additional context, used by context-dependent metrics- Conversation tracking fields (
conversation_id,session_id,thread_id, etc.) — used for multi-turn conversation management
Stored and available to metrics:
metadata— stored with the test result, available to custom metricstool_calls— stored with the test result, available to metrics that evaluate tool use
Custom fields beyond these are passed through and stored but not actively used by the platform.
SDK endpoint return values
For SDK connection-type endpoints, response mapping is applied only when the
decorated function returns a dictionary. If the function returns a string, list,
or another non-dictionary value, Rhesis skips the configured response mapping and
wraps the value as output.
Return a dictionary when you need response mapping to extract multiple fields:
Complete Example
Request headers:
Request body template:
Response mapping:
Next steps
- Examples — provider-specific configurations
- Request Mapping — template syntax and filters