Skip to Content
DocsEndpointsOverview

Endpoints

An endpoint is how Rhesis connects to your AI model or application to send test inputs and evaluate responses.

There are two ways to set one up depending on how your model is exposed:

  • REST or WebSocket — your model is behind an HTTP API. You configure the URL, authentication, and request/response mappings directly in the platform. This is the most common case.
  • SDK — your model is a Python function with no HTTP layer. You register it as an endpoint using the @endpoint decorator from the Rhesis SDK. See SDK Endpoints.

Once configured, an endpoint can be reused across any number of tests and test sets. You can also run the same tests against multiple endpoints to compare models, environments, or configurations.

Platform-Managed Variables

Rhesis populates these variables at runtime; you reference them in request templates and extract them in response mappings.

Request Variables

Available in request body templates via Jinja2 syntax ({{ variable }}).

VariableDescription
inputThe user query or test prompt. This is the primary text sent to your AI endpoint.
filesArray of file attachments included with the test. Each file is an object with filename, content_type, and data (base64-encoded). Use file format filters to convert files into provider-specific formats.
conversation_idConversation tracking identifier for multi-turn endpoints (both stateful and stateless). Rhesis uses this to track conversations across turns.
messagesFull conversation history as an array of message objects. Used for stateless endpoints that require the entire history with every request.
system_promptSystem prompt text. Rhesis prepends it to the messages array and strips it from the final request body before sending.
paramsResolved experiment parameters for the current test run. Access individual values with dot notation: {{ params.model }}, {{ params.temperature }}. Only populated when the test run is associated with an experiment; empty dict otherwise. See Using Experiment Parameters below.
test_idUnique identifier of the test being executed. Only populated during test runs; renders as an empty string otherwise. Place it wherever your API expects it — see Test Execution Context for examples.
test_run_idUnique identifier of the current test run. Only populated during test runs; renders as an empty string otherwise.
test_configuration_idUnique identifier of the test configuration driving the run. Only populated during test runs; renders as an empty string otherwise.

Provider-specific Jinja filters such as to_anthropic, to_openai, and to_gemini are documented in Single-Turn Endpoints.

Response Variables

Extracted from your API response using JSONPath or Jinja2 expressions in the response mapping.

VariableDescription
outputThe main response text from your API. This is what Rhesis evaluates against your metrics.
contextAdditional context or reasoning provided by the response (e.g., retrieved documents, sources).
metadataStructured data about the response (e.g., model version, token counts, confidence scores). Stored with the test result and available to custom metrics during evaluation.
tool_callsTool or function calls made by the API during response generation. Stored with the test result and available to metrics that evaluate tool use.
Conversation ID fieldsAny of the recognized conversation identifiers: conversation_id, session_id, thread_id, chat_id, dialog_id, dialogue_id, context_id, interaction_id. Map one of these for multi-turn endpoints so Rhesis can track conversations across turns.

You can include additional custom fields in both request templates and response mappings. Custom fields are passed through and stored, but Rhesis does not actively use them for evaluation or conversation management.

Request mapping uses Jinja2 templates to format platform variables into your API’s request body. Response mapping uses JSONPath expressions to extract values from the response. For full details, see Request Mapping and Response Mapping.

Using Experiment Parameters

When you run tests against an experiment, Rhesis resolves the experiment’s parameter values and makes them available in your request mapping under the params variable. This lets you drive model selection, temperature, system prompts, and any other configuration directly from the experiment — without changing your endpoint definition.

Accessing parameters in request mappings

Use Jinja2 dot notation to reference individual parameter values:

request-mapping-with-params.json
{
"model": "{{ params.model }}",
"messages": [
  {
    "role": "system",
    "content": "{{ params.system_prompt }}"
  },
  {
    "role": "user",
    "content": "{{ input }}"
  }
],
"temperature": {{ params.temperature }},
"max_tokens": {{ params.max_tokens }}
}

Numeric and boolean parameters (like temperature or max_tokens) should be referenced without quotes so they render as JSON numbers or booleans rather than strings.

When no experiment is associated with a test run, params is an empty object and unresolved references render as empty strings. You can use Jinja2 defaults to handle this gracefully:

request-mapping-with-defaults.json
{
"model": "{{ params.model | default('gpt-4') }}",
"temperature": {{ params.temperature | default(0.7) }}
}

SDK connector endpoints can also receive parameters as keyword arguments or via Parameters.get() — see Connector Injection.

Managing Endpoints

  • Edit — Open the detail page, click Edit, update any fields, click Save.
  • Duplicate — Click Duplicate on the detail page to copy the full configuration. “(Copy)” is appended to the name. You can also bulk-duplicate from the grid.
  • Delete — Select one or more endpoints from the grid and click Delete. Historical test results are preserved.

The detail page has four tabs: Overview (template + response mapping), Headers (auth token + custom headers), Test (interactive test-and-map workbench), and Test Runs (execution history).

Next Steps

Conversation TracingCreating Endpoints