Guard
Reliant Guard is an AI conversation guardrails layer. It sits between your user and any AI — validating responses against Topic, Data Shield, and Tone rules before delivery. One API call replaces fragile prompt engineering with runtime enforcement.
POST /guard/chat
The recommended endpoint. Guard calls your configured AI provider internally, validates the response through all active layers, and returns the final safe response — in a single call.
Body
| Field | Type | Required | Description |
|---|---|---|---|
| user_message | string | yes | The message sent by the end user |
| guard_id | string | yes | Guard config ID created in Dashboard → Guard |
| user_id | string | yes | Your User ID (Dashboard → Settings) |
Response
| Field | Type | Description |
|---|---|---|
| allowed | boolean | Whether the response passed all guard layers |
| response | string | The final response to deliver to the user. Safe response if blocked. |
| blocked_by | string | null | topic, data, tone, or null if allowed |
| block_reason | string | null | Human-readable explanation of why it was blocked |
| latency_ms | number | Total latency including AI call and all validation layers |
POST /guard
Validate-only endpoint. Pass your own AI response for Guard to inspect. Use this when you already have the AI response and just need the validation layer.
Guard layers
◎ Topic Guard
Defines what the AI is allowed or not allowed to discuss. Uses LLM-as-judge to evaluate whether the response stays within the configured scope. Configure allowed_topics and blocked_topics in the Guard dashboard.
◫ Data Shield
Blocks responses containing sensitive data patterns or keywords. Runs instantly using regex and string matching — no LLM cost. Configure blocked_keywords and blocked_patterns (regex) in the Guard dashboard.
◈ Tone & Compliance
Enforces brand voice and content policies. Uses LLM-as-judge to evaluate whether the response matches your configured tone_rules. Blocked phrases run instantly without LLM cost.
Integration example
Complete WhatsApp bot integration using /guard/chat:
response field is always safe to deliver to the user — whether the request was allowed or blocked. You don't need to check allowed unless you want to log or handle blocked requests differently.⬡ Reliant Limits
Limits control how many executions a project or an end-user can make within a period. When a limit is reached, the configured safe_response is returned automatically — no error, no broken app.
| Field | Type | Description |
|---|---|---|
| max_executions_per_period | number | Max executions for the whole project per period |
| period_type | string | hourly, daily, or monthly |
| limit_response | string | Response returned when project limit is reached |
| max_executions_per_user | number | Max executions per end-user per period |
| user_period_type | string | hourly, daily, or monthly |
| user_limit_response | string | Response returned when user limit is reached |
To enable per-user tracking, pass end_user_id in the /guard/chat request body — typically a phone number, user ID, or session token.
When a limit is hit, the response looks like this:
GET /guard/usage/:guard_id
Returns current period usage for a Guard — project total and top end-users by volume.
Guard config endpoints
GET /guard/configs
List all Guard configs for the authenticated project.
POST /guard/configs
Create a Guard config programmatically.
PUT /guard/configs/:id
Update a Guard config.
DELETE /guard/configs/:id
Delete a Guard config.