Skip to main content
When you enable output guardrails on streaming requests, Portkey accumulates the full response after the stream completes, runs your guardrail checks, and sends the results as an additional SSE chunk. Unlike non-streaming requests, no server-side action is taken — retry, fallback, and deny are not triggered automatically. The results are informational, giving you full control to handle them on the client side. This guide walks through capturing those results and building client-side handling patterns like retry, fallback, and content filtering.

Prerequisites

  • A Portkey account with an API key
  • An output guardrail created in the Portkey dashboard (e.g., sentence count, word count, regex match, or any custom check)
  • The guardrail’s ID (visible after saving it in the dashboard)
To receive hook_results in streaming chunks, you must set the x-portkey-strict-open-ai-compliance header to false. Without this, guardrail is executed but the result chunks are not sent to be compliant with the spec.

How streaming output guardrails work

  1. You send a streaming request with output guardrails configured
  2. Portkey streams the LLM response chunks to you normally
  3. After the final [DONE] chunk, Portkey sends one additional chunk containing hook_results with the after_request_hooks array
  4. Your client can inspect the verdict and decide what to do — retry, fall back to another model, filter the response, or surface a warning

Step 1: Configure the request

Add your output guardrail to the config using afterRequestHooks (or output_guardrails in a saved config). Set stream: true and disable strict OpenAI compliance.

Step 2: Capture guardrail results from the stream

Iterate over the stream, collect content chunks, and extract hook_results from the final chunk.

Step 3: Inspect the verdict

Each guardrail in after_request_hooks returns a verdict (boolean) and an array of checks. A guardrail’s overall verdict is true only when all its checks pass.
The hook_results chunk for output guardrails looks like this:

Client-side handling patterns

Since streaming output guardrails are informational only, you implement the handling logic yourself. Here are common patterns:

Pattern 1: Client-side retry

Re-send the request when the guardrail fails, optionally with a modified prompt to steer the model toward compliant output.

Pattern 2: Client-side fallback to another model

If the primary model’s output fails guardrails, fall back to a different model.

Pattern 3: Conditional content filtering

Show or hide the streamed response based on specific check results.

Pattern 4: Logging and observability

Log guardrail outcomes for monitoring without blocking the response.

Combining patterns

You can chain these patterns together for robust handling:

Important considerations

  • Output guardrails on streaming are informational only. Portkey does not trigger server-side retry, fallback, or deny for output guardrails in streaming mode. You must handle these on the client side.
  • Set x-portkey-strict-open-ai-compliance to false to receive the hook_results chunk. This header defaults to true.
  • Async guardrails do not return results in the response. If your guardrail is configured with async=true, results appear only in Portkey logs, not in the stream.
  • The full response is evaluated. Portkey assembles all stream chunks and runs checks on the complete text, so partial-stream checks are not supported.
  • Anthropic /messages endpoint: Hook results cannot be accessed through the Anthropic SDK. Use cURL or raw HTTP requests for that endpoint.

Next steps

Last modified on July 24, 2026