Input Schema

The input schema defines what data your endpoint accepts. When a request comes in, Endprompt validates it against your schema before processing—rejecting invalid requests with clear error messages.

Why Define Input Schema?

Automatic Validation

Invalid requests are rejected before hitting the LLM, saving costs

Clear Documentation

Your OpenAPI docs are auto-generated from your schema

Type Safety

Ensure prompts receive data in the expected format

Default Values

Provide sensible defaults for optional fields

Adding Input Fields

Navigate to your endpoint’s Input Schema tab and click Add Field.

Field Configuration

Property	Required	Description
Name	Yes	Field identifier used in templates (`{{ inputs.name }}`)
Type	Yes	Data type (see types below)
Required	No	Whether the field must be provided
Default	No	Value to use if field is not provided
Description	No	Help text shown in docs and test forms

Field Types

Text values of any length.

{
  "name": "query",
  "type": "string",
  "required": true,
  "description": "The search query"
}

Validation options:

minLength — Minimum character count
maxLength — Maximum character count
pattern — Regex pattern to match
enum — List of allowed values

Decimal numbers (floats).

{
  "name": "temperature",
  "type": "number",
  "required": false,
  "default": 0.7
}

Validation options:

minimum — Minimum value
maximum — Maximum value

Whole numbers only.

{
  "name": "max_results",
  "type": "integer",
  "required": false,
  "default": 10
}

Validation options:

minimum — Minimum value
maximum — Maximum value

True or false values.

{
  "name": "include_examples",
  "type": "boolean",
  "required": false,
  "default": false
}

Lists of values.

{
  "name": "tags",
  "type": "array",
  "items": { "type": "string" },
  "required": false
}

Validation options:

minItems — Minimum array length
maxItems — Maximum array length
items — Schema for array elements

Nested JSON objects.

{
  "name": "options",
  "type": "object",
  "properties": {
    "format": { "type": "string" },
    "length": { "type": "integer" }
  }
}

Validation Rules

Add validation rules to ensure data quality:

String Validation

{
  "name": "email",
  "type": "string",
  "required": true,
  "minLength": 5,
  "maxLength": 254,
  "pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
}

Enum (Allowed Values)

{
  "name": "tone",
  "type": "string",
  "required": true,
  "enum": ["formal", "casual", "friendly", "professional"]
}

Use enums when you have a fixed set of valid options. They generate dropdowns in the test form and are documented in OpenAPI.

Number Ranges

{
  "name": "confidence_threshold",
  "type": "number",
  "required": false,
  "default": 0.8,
  "minimum": 0,
  "maximum": 1
}

Array Limits

{
  "name": "categories",
  "type": "array",
  "items": { "type": "string" },
  "minItems": 1,
  "maxItems": 10
}

Using Inputs in Prompts

Once defined, access input fields in your prompts using Liquid syntax:

Summarize the following {{ inputs.content_type }} content:

{{ inputs.text }}

{% if inputs.include_keywords %}
Also extract the top {{ inputs.keyword_count | default: 5 }} keywords.
{% endif %}

Keep the summary under {{ inputs.max_words | default: 100 }} words.

Use the | default: filter to provide fallback values for optional fields.

JSON Schema Preview

The Input Schema tab shows a live JSON Schema preview:

{
  "type": "object",
  "required": ["text"],
  "properties": {
    "text": {
      "type": "string",
      "description": "The content to summarize",
      "minLength": 10,
      "maxLength": 50000
    },
    "max_words": {
      "type": "integer",
      "description": "Maximum words in summary",
      "default": 100,
      "minimum": 10,
      "maximum": 1000
    },
    "format": {
      "type": "string",
      "description": "Output format",
      "enum": ["paragraph", "bullets", "numbered"],
      "default": "paragraph"
    }
  }
}

This schema is used for:

Request validation
OpenAPI documentation
Test form generation

Best Practices

Use descriptive names

Field names should be clear and self-documenting.✅ customer_feedback
❌ cf

Always add descriptions

Descriptions appear in docs and help users understand what to provide.

Set sensible defaults

Optional fields should have reasonable defaults so users don’t need to specify everything.

Validate early

Use minLength, maxLength, and patterns to catch bad data before it reaches the LLM.

Keep schemas flat

Avoid deeply nested objects. Flat schemas are easier to understand and template.

Example: Complete Input Schema

Here’s a full example for a content moderation endpoint:

Field	Type	Required	Default	Description
`content`	string	Yes	—	The content to moderate
`content_type`	string	Yes	—	Type: text, image_url, or html
`categories`	array	No	all	Categories to check
`threshold`	number	No	0.7	Confidence threshold (0-1)
`include_explanation`	boolean	No	false	Include reasoning

Getting Started

Endpoints

Prompts

LLM Models

Why Define Input Schema?

Automatic Validation

Clear Documentation

Type Safety

Default Values

Adding Input Fields

Field Configuration

Field Types

Validation Rules

String Validation

Enum (Allowed Values)

Number Ranges

Array Limits

Using Inputs in Prompts

JSON Schema Preview

Best Practices

Example: Complete Input Schema

Next Steps

Define Output Schema

Create a Prompt

Getting Started

Endpoints

Prompts

LLM Models

​Why Define Input Schema?

Automatic Validation

Clear Documentation

Type Safety

Default Values

​Adding Input Fields

​Field Configuration

​Field Types

​Validation Rules

​String Validation

​Enum (Allowed Values)

​Number Ranges

​Array Limits

​Using Inputs in Prompts

​JSON Schema Preview

​Best Practices

​Example: Complete Input Schema

​Next Steps

Define Output Schema

Create a Prompt

Why Define Input Schema?

Adding Input Fields

Field Configuration

Field Types

Validation Rules

String Validation

Enum (Allowed Values)

Number Ranges

Array Limits

Using Inputs in Prompts

JSON Schema Preview

Best Practices

Example: Complete Input Schema

Next Steps