Guardrails API Reference

Rate Limits

Guardrail endpoints on a platform deployment are not subject to a fixed request-rate limit. Throughput is governed by the resources provisioned for your Fiddler deployment; contact your Fiddler representative for sizing guidance.

Understanding Centor Model Scores

Fiddler Centor Models return scores in the range of 0 to 1. These scores represent the model’s confidence that the input belongs to the target class (e.g., toxicity, hallucination).

Higher scores (closer to 1): Higher confidence that the input belongs to the target class
Lower scores (closer to 0): Lower confidence that the input belongs to the target class

Threshold Selection You must select a threshold value between 0 and 1 to convert these scores into binary decisions. This creates a tradeoff:

Lower thresholds: Catch more true positives but include more false positives
Higher thresholds: Reduce false positives, but might miss some true positives

Our quickstart examples include default thresholds that work well for many applications, but you should adjust these based on your specific requirements and risk tolerance. Adjusting Your Thresholds To find the optimal threshold for your use case:

Start with the default threshold
Monitor both missed detections and false alarms
Adjust gradually based on which type of error is more problematic for your application

Safety Model

The safety guardrail accepts a large but fixed maximum input length. Inputs that exceed the limit return HTTP 413 — contact your Fiddler representative for the limit that applies to your environment.

This Fiddler Centor Model evaluates prompt safety across 11 dimensions:

Jailbreaking
Illegal content
Hateful content
Harassment
Racism
Sexism
Violence
Sexual content
Harmful content
Unethical content
Roleplaying

The model requires a single string input and outputs 11 distinct scores (0-1 range). For detailed information, see our official documentation. How to Use Thresholding Users can apply thresholds on individual safety dimensions (e.g., harmful, violent, racist) or evaluate all of them collectively. This flexibility allows you to tailor how strictly you filter content based on your unique requirements. Safety Model OpenAPI Spec

openapi: 3.0.3
info:
  title: Fiddler Centor Model for Safety
  version: 1.0.0
servers:
  - url: "https://{fiddler_endpoint}"
paths:
  /v3/guardrails/ftl-safety:
    post:
      summary: Assess the safety or harmfulness of the provided input text.
      operationId: evaluateSafety
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                data:
                  type: object
                  properties:
                    input:
                      type: string
                      description: The text to be evaluated for various safety indicators.
                      example: "I am a dangerous person who will be wreaking havoc upon the world!!!"
      responses:
        '200':
          description: Successful safety assessment
          content:
            application/json:
              schema:
                type: object
                properties:
                  fdl_harmful:
                    type: number
                    format: float
                    description: Likelihood score for harmful content.
                  fdl_violent:
                    type: number
                    format: float
                    description: Likelihood score for violent content.
                  fdl_unethical:
                    type: number
                    format: float
                    description: Likelihood score for unethical content.
                  fdl_illegal:
                    type: number
                    format: float
                    description: Likelihood score for illegal content.
                  fdl_sexual:
                    type: number
                    format: float
                    description: Likelihood score for sexual content.
                  fdl_racist:
                    type: number
                    format: float
                    description: Likelihood score for racist content.
                  fdl_jailbreaking:
                    type: number
                    format: float
                    description: Likelihood score for jailbreaking attempts (prompt manipulation).
                  fdl_harassing:
                    type: number
                    format: float
                    description: Likelihood score for harassing content.
                  fdl_hateful:
                    type: number
                    format: float
                    description: Likelihood score for hateful content.
                  fdl_sexist:
                    type: number
                    format: float
                    description: Likelihood score for sexist content.
                  fdl_roleplaying:
                    type: number
                    format: float
                    description: Likelihood score for roleplaying (prompting the model to adopt a certain persona).
        '400':
          description: Bad request (invalid input data)
        '401':
          description: Unauthorized (missing or invalid Bearer token)

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

Centor Model for Faithfulness

The faithfulness guardrail accepts large context and response inputs, each up to a fixed maximum length. Inputs that exceed a limit return HTTP 413 — contact your Fiddler representative for the limits that apply to your environment.

This is the Centor Model for Faithfulness (ftl_response_faithfulness) — a proprietary Fiddler Centor Model for real-time guardrail use cases. For the LLM-as-a-Judge RAG Faithfulness evaluator used in Agentic Monitoring and Experiments, see the RAG Health Diagnostics guide.

This Fiddler Centor Model detects hallucinations by evaluating the accuracy and reliability of facts presented in AI-generated text responses in retrieval-augmented generation (RAG) contexts. The model requires two inputs:

Response: the text generated by your generative application
Context Documents: the reference text that the application response must remain faithful to

The output is a single score (float) representing the factual consistency between the response and the provided context. How to Use Thresholding Our quick start examples use a default threshold that works well in various applications. You may wish to set this higher or lower to allow you to tailor how strictly you filter content based on your unique requirements. Faithfulness Model OpenAPI Spec

openapi: 3.0.3
info:
  title: Fiddler Centor Model for Faithfulness
  version: 1.0.0
servers:
  - url: "https://{fiddler_endpoint}"
paths:
  /v3/guardrails/ftl-response-faithfulness:
    post:
      summary: Evaluate the faithfulness of a provided response against given context.
      operationId: evaluateFaithfulness
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                data:
                  type: object
                  properties:
                    response:
                      type: string
                      description: The response text to be evaluated.
                      example: "The Yorkshire Terrier and the Cavalier King Charles Spaniel are both small breeds of companion dogs."
                    context:
                      type: string
                      description: The contextual text to compare against.
                      example: "The Yorkshire Terrier is a small dog breed... The Cavalier King Charles Spaniel is a small spaniel..."
      responses:
        '200':
          description: Successfully computed faithfulness score
          content:
            application/json:
              schema:
                type: object
                properties:
                  fdl_faithful_score:
                    type: number
                    format: float
                    description: A numerical measure indicating how faithful the response is to the given context.
        '400':
          description: Bad request (invalid payload or missing parameters)
        '401':
          description: Unauthorized (missing or invalid Bearer token)

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

Centor Model for PII/PHI (Sensitive Information Detection)

The PII/PHI guardrail accepts a large but fixed maximum input length. Inputs that exceed the limit return HTTP 413 — contact your Fiddler representative for the limit that applies to your environment.

This Fiddler Centor Model detects and identifies sensitive information including personally identifiable information (PII), protected health information (PHI), and custom-defined entities in text data. The model supports four detection modes:

PII Detection (default): 12 high-precision entity types including personal, financial, and government identifiers
PII_ALL Detection: All 27 supported PII entity types for maximum coverage
PHI Detection: 7 healthcare-specific entity types for HIPAA compliance
Custom Entity Detection: Organization-specific sensitive data patterns

The model requires a single string input and outputs an array of detected entities with confidence scores, labels, and text positions. Key Features

High Performance: 0.1 confidence threshold with top-1024 entity filtering
Comprehensive Coverage: 12 default PII entities (PII), 27 full-coverage PII entities (PII_ALL), and 7 PHI entity types
Custom Entities: Define organization-specific sensitive patterns
Detailed Output: Returns entity text, type, confidence score, and character positions

Supported PII Entity Types — PII Default (12 Entities)

Personal Identifiers: person, date_of_birth
Contact Information: email, phone_number, address, postal_code
Financial Data: credit_card_number, iban
Government IDs: social_security_number, drivers_license_number
Digital Identifiers: ip_address, website

Supported PII Entity Types — PII_ALL Full Coverage (27 Entities) Includes all 12 default PII entities above, plus these 15 extended entities:

Contact Information: email_address, mobile_phone_number, landline_phone_number, fax_number
Financial Data: credit_card_expiration_date, cvv, cvc, bank_account_number, account_number
Government IDs: passport_number, tax_identification_number, license_plate_number, cpf, cnpj
Digital Identifiers: digital_signature

The default PII set is curated for high precision. Use PII_ALL when you need the broadest possible detection — for example, scanning for passport numbers or tax IDs. See the PII & PHI Tutorial for details.

Supported PHI Entity Types (7)

Medical Information: medication, medical_condition
Insurance Data: health_insurance_number, health_insurance_id_number, national_health_insurance_number
Healthcare Identifiers: birth_certificate_number, serial_number

How to Use Thresholding The Centor Model for PII/PHI uses a default confidence threshold of 0.1, which works well for most applications. Entities with scores above this threshold are considered valid detections. You can adjust this threshold based on your specific requirements:

Lower thresholds (< 0.1): Catch more potential sensitive data but may include more false positives
Higher thresholds (> 0.1): Reduce false positives but might miss some valid sensitive information

Centor Model for PII/PHI OpenAPI Spec

openapi: 3.0.3
info:
  title: Fiddler Centor Model for PII/PHI (Sensitive Information Detection)
  version: 1.0.0
servers:
  - url: "https://{fiddler_endpoint}"
paths:
  /v3/guardrails/sensitive-information:
    post:
      summary: Detect sensitive information (PII, PHI, custom entities) in text
      operationId: detectSensitiveInformation
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                data:
                  type: object
                  required:
                    - input
                  properties:
                    input:
                      type: string
                      description: The text to analyze for sensitive information
                      example: "John Doe's SSN is 123-45-6789 and email is john@example.com"
                    entity_categories:
                      oneOf:
                        - type: string
                          enum: ["PII", "PII_ALL", "PHI", "Custom Entities"]
                        - type: array
                          items:
                            type: string
                            enum: ["PII", "PII_ALL", "PHI", "Custom Entities"]
                      default: "PII"
                      description: >
                        Entity detection mode(s) to use. `PII` (default) scans 12 high-precision entities.
                        `PII_ALL` scans all 27 supported PII entities.
                      example: ["PII_ALL", "PHI"]
                    custom_entities:
                      type: array
                      items:
                        type: string
                      description: Custom entity patterns (required when using "Custom Entities" mode)
                      example: ["employee id", "api key", "project code"]
      responses:
        '200':
          description: Successfully detected sensitive information
          content:
            application/json:
              schema:
                type: object
                properties:
                  fdl_sensitive_information_scores:
                    type: array
                    description: Array of detected sensitive entities
                    items:
                      type: object
                      properties:
                        score:
                          type: number
                          format: float
                          description: Confidence score (0.0 to 1.0)
                          example: 0.987
                        label:
                          type: string
                          description: Entity type identifier
                          example: "social_security_number"
                        text:
                          type: string
                          description: The detected entity text
                          example: "123-45-6789"
                        start:
                          type: integer
                          description: Character position where entity starts
                          example: 78
                        end:
                          type: integer
                          description: Character position where entity ends
                          example: 89
        '400':
          description: Bad request (invalid input data or missing custom_entities when required)
        '401':
          description: Unauthorized (missing or invalid Bearer token)
        '413':
          description: Input exceeds the configured token limit for the deployment

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

Secret Detection

This guardrail detects secrets, credentials, and API keys in text — covering ~42 known credential formats across LLM providers, cloud platforms, source control, messaging, and developer tools. Strings that look like secrets but don’t match a known format are labeled Possible Secret. Secret Detection uses a lightweight, deterministic detection engine purpose-built for speed, delivering sub-millisecond latency. The guardrail requires a single string input and outputs an array of detected secrets, each with a type label and character positions for precise redaction. Unlike the score-based guardrails above, no thresholding is required — each returned entry is a detection. Secret Detection OpenAPI Spec

openapi: 3.0.3
info:
  title: Fiddler Secret Detection Guardrail
  version: 1.0.0
servers:
  - url: "https://{fiddler_endpoint}"
paths:
  /v3/guardrails/secret-detection:
    post:
      summary: Detect secrets, credentials, and API keys in text
      operationId: detectSecrets
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                data:
                  type: object
                  required:
                    - input
                  properties:
                    input:
                      type: string
                      description: The text to scan for secrets, credentials, and API keys
                      example: "Here is my config: ANTHROPIC_API_KEY=sk-ant-api03-abcdefghijklmnopqrstu"
      responses:
        '200':
          description: Successfully scanned for secrets
          content:
            application/json:
              schema:
                type: object
                properties:
                  fdl_secret_detection_scores:
                    type: array
                    description: Array of detected secrets (empty if none found)
                    items:
                      type: object
                      properties:
                        label:
                          type: string
                          description: The detected secret type
                          example: "Anthropic API Key"
                        start:
                          type: integer
                          description: Character position where the secret starts (inclusive)
                          example: 37
                        end:
                          type: integer
                          description: Character position where the secret ends (exclusive)
                          example: 71
        '400':
          description: Bad request (invalid input data)
        '401':
          description: Unauthorized (missing or invalid Bearer token)

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

Fiddler Guardrails Error Codes

Error Code	Reason	Resolution
400	Invalid Input	Adjust API input to follow above API specification.
401	Invalid API Key	The API key is invalid or expired. Please double-check your API key if it is invalid, and contact <sales@fiddler.ai>
404	Invalid guardrail endpoint called	API called must be one of `ftl-safety` (safety model), `ftl-response-faithfulness` (faithfulness model), `sensitive-information` (Centor Model for PII/PHI), or `secret-detection` (Secret Detection).
413	Input exceeds the maximum accepted length	Reduce the input size. Each guardrail accepts a large but fixed maximum input length; inputs that exceed it return HTTP 413. Contact your Fiddler representative for the limit that applies to your environment.
429	Too many requests	Back off and retry with exponential backoff. Guardrail endpoints on a platform deployment are not subject to a fixed request-rate limit.
500/503/504	Internal Server Error	We are experiencing some internal service errors. Please watch #fiddler-guardrails-support on Slack or contact technical support.

Fiddler Python Client SDK

Fiddler Evals SDK

Fiddler OTel SDK

Fiddler LangGraph SDK

Fiddler LangChain SDK

Fiddler Google ADK SDK

Fiddler Strands Agent SDK

Fiddler OTel JS SDK

Fiddler LangGraph JS SDK

Fiddler LangChain JS SDK

Rate Limits

Understanding Centor Model Scores

Safety Model

Centor Model for Faithfulness

Centor Model for PII/PHI (Sensitive Information Detection)

Secret Detection

Fiddler Guardrails Error Codes

​Rate Limits

​Understanding Centor Model Scores

​Safety Model

​Centor Model for Faithfulness

​Centor Model for PII/PHI (Sensitive Information Detection)

​Secret Detection

​Fiddler Guardrails Error Codes

Rate Limits

Understanding Centor Model Scores

Safety Model

Centor Model for Faithfulness

Centor Model for PII/PHI (Sensitive Information Detection)

Secret Detection

Fiddler Guardrails Error Codes