Integration

Choose your boundary

Most teams redact user input before it crosses the model boundary, then inspect model output again before storing, displaying, or sending it elsewhere. Use the second pass when your threat model requires it; Redax does not automatically make the rest of your application safe.

user message → Redax → LLM → Redax → UI / storage

Python boundary function

Keep the HTTP call in a small function so the rest of your application never has to remember which fields are sensitive. This uses the real endpoint and response field; a non-2xx response raises before any downstream model call can happen.

import httpx


async def redact_before_model(message: str, api_key: str) -> str:
    async with httpx.AsyncClient(base_url="http://localhost:8000", timeout=30.0) as client:
        response = await client.post(
            "/v1/redact",
            headers={"X-API-Key": api_key},
            json={"text": message, "use_pipeline": True},
        )
        response.raise_for_status()
        return response.json()["text"]


# Pass only the returned string to your existing model client.
safe_message = await redact_before_model(
    "Synthetic contact alice@example.com",
    api_key="your-injected-key",
)

Need a synchronous script or Redis/telemetry setup? Use the practical examples.

Decide what to do with placeholders

Typed placeholders preserve the shape of a conversation without preserving the identifying value. Keep them when the model only needs context; use a policy strategy such as hash when you need stable joins; restore values only inside a controlled, audited system that has a real business reason to do so.

Handle failures explicitly

Treat a failed redaction as a failed privacy check. Do not silently fall back to sending the raw prompt to the model. Retry with an idempotency key for transient failures, or return a user-safe error while your service checks /readyz and its own dependency health.