Visual Designer
Form-Based Editing
The Visual Designer provides a form-based interface to edit every part of your OpenAPI spec. No YAML or JSON knowledge required - changes are automatically converted to the spec format.
State Persistence
The Visual Designer remembers your view state per project:
Expanded Sections
Which sections are open
Scroll Position
Jump back to where you were
Expanded Paths
Which paths are expanded
Default State
When opening a project for the first time, the Info and Paths sections are expanded by default.
Empty & Error States
The Visual Designer shows helpful messages when the spec isn't ready:
Shown when there's no valid OpenAPI spec. Prompts you to edit the code or paste a valid spec in the Code Editor.
Shown when the spec has validation errors. Lists the errors and hides the visual editor until you fix them in the Code Editor.
Collapsible Sections
The Visual Designer organizes the spec into collapsible sections:
Info Section
Edit your API's basic information:
Servers Section
Define base URLs for your API. Supports server variables for dynamic parts.
No variables defined
Tags (Modules) Section
Tags in OpenAPI become Modules in Tigrister. They group related endpoints together.
User management operations
Order processing endpoints
Paths (Endpoints) Section
Add and edit API paths and their operations:
Schemas (Models) Section
Define reusable data models for requests and responses. Full support for JSON Schema.
Supported Types
Features
- • $ref references to other schemas
- • allOf / oneOf / anyOf composition
- • Enum values
- • Min/max constraints
- • Pattern validation (regex)
- • Format hints (email, date, uuid, etc.)
Schema Composition in Visual Designer
Create complex schemas using composition keywords directly in the Visual Designer:
Combine multiple schemas. The result must satisfy ALL schemas (like interface extension).
User has all properties from both BaseEntity and UserFields.
Value must match exactly ONE of the schemas (like union types with discriminator).
A Pet is either a Cat, Dog, or Bird - never multiple. Use with discriminator.
Value must match AT LEAST ONE schema (more flexible than oneOf).
PaymentID can be either a string or integer (useful for flexible inputs).
Adding Composition in Visual Designer
- Open a schema in the Visual Designer
- Click "Add Composition" button
- Choose allOf, oneOf, or anyOf
- Select existing schemas to combine, or create inline schemas
- For oneOf, optionally set a discriminator property
Security Schemes Section
Define authentication methods for your API:
API Key
Authentication via header, query, or cookie.
HTTP Auth
Basic auth, Bearer token, etc.
OAuth 2.0
Full OAuth 2.0 flows with scopes.
OpenID Connect
Discover auth endpoints from URL.
Security Scheme Setup Walkthrough
Follow these steps to set up authentication for your API in the Visual Designer:
Open Security Schemes Section
Click on "Security Schemes" in the Visual Designer sidebar to expand the section.
Add New Security Scheme
Click "+ Add Security Scheme" and choose the authentication type:
Configure the Scheme
Fill in the required fields based on your authentication type:
Apply to Operations
Two ways to require authentication:
Add to top-level security array. Applies to all endpoints by default.
Add to specific operation's security. Overrides global setting.
OAuth 2.0 Configuration
For OAuth 2.0, you'll also need to configure:
- • Authorization URL - Where users log in
- • Token URL - Where tokens are exchanged
- • Scopes - Permissions (e.g., read:users, write:orders)
- • Flow type - authorizationCode, implicit, clientCredentials, password
Webhooks Section
OpenAPI 3.1Define webhooks that your API sends to external services. Available only in OpenAPI 3.1 specs.
Fired when a new order is placed
Managing Webhooks
OpenAPI 3.1+Webhooks document the HTTP callbacks your API makes to external systems. Here's how to manage them:
Creating a Webhook
- Ensure your spec is OpenAPI 3.1 (webhooks aren't supported in 3.0)
- Click "+ Add Webhook" in the Webhooks section
- Enter a descriptive name (e.g.,
orderCreated) - Define the request method (usually POST)
- Specify the request body schema that will be sent
- Document expected responses from the receiving server
Webhook Structure
Good Practices
- • Include event type in the payload
- • Add timestamp for ordering
- • Include idempotency key
- • Document retry behavior
- • Define signature header for verification
Common Events
- •
order.created - •
payment.completed - •
user.registered - •
subscription.cancelled - •
invoice.paid
OpenAPI 3.0 Alternative
If you need webhook-like documentation in OpenAPI 3.0, use operation-level callbacks instead. Callbacks are tied to specific operations and use runtime expressions for the callback URL.
Callbacks (Operation-level)
OpenAPI 3.0+Callbacks define asynchronous, out-of-band requests that your API makes in response to certain events. Unlike webhooks, callbacks are tied to specific operations.
Callbacks (3.0+)
- • Tied to a specific operation
- • URL uses runtime expressions
- • Triggered by the operation's response
- • Example: Payment notification after checkout
Webhooks (3.1+)
- • Standalone, not tied to operations
- • URL configured externally
- • Triggered by any event
- • Example: Order status change event
Callback Structure
The callback URL is extracted from the request body using a runtime expression.
Adding Callbacks in Visual Designer
- Navigate to Paths section and expand an operation
- Scroll to the "Callbacks" subsection
- Click "+ Add Callback"
- Enter callback name and runtime expression URL
- Define the callback's request/response schema