Style Guide

The API Style Guide enforces consistent design standards across every specification in your organization. Routebase ships with 57 built-in linting rules — covering naming, completeness, best practices, security, and structure — and lets you add custom rules on top. Violations surface live in the API Designer and can block publishing.

The Style Guide is available on the Pro plan; on lower plans the settings page shows an upgrade prompt. Configuring it requires the org:manage-governance permission (Admins and Owners).

Configuring the style guide

Open Settings → Style Guide: "Configure organization-wide style guide rules. These settings apply to all projects unless overridden."

The General card controls enforcement behavior:

Setting	Description	Default
Style Guide	Enable automated design governance for your API specifications.	On
Enforce on Publish	Block publishing API versions that have error-level violations.	Off

Click Save Changes to apply (or Reset to discard).

Rules and severities

The Rules card lists every rule with its category badge, name, target, and a severity dropdown. Filter by category, search by name, and page through the list. Each rule's severity can be set to:

Severity	Effect
Error	Blocks publishing when Enforce on Publish is enabled.
Warning	Reported, but never blocks.
Info	Informational hint.
Off	Rule disabled.

Rules you've changed from their default are marked with an override badge and can be reset to the default with one click. Rules that only apply to OpenAPI 3.0 specs carry a 3.0 only badge; your own rules carry a custom badge.

Naming conventions

Some naming rules don't hard-wire the convention they enforce — for those the table shows a Convention column with a dropdown, and the rule checks whatever you pick there.

The rule for URL paths is the one that matters in practice: it defaults to kebab-case but also accepts camelCase, PascalCase and lowercase. So a team that has always written /userProfiles doesn't have to choose between switching its whole URL scheme and turning the rule off — it sets the convention and keeps the check.

Project-level overrides

Each project can override severities for its own specs: open the project and use its Style Guide tab. The project view adds a Source column showing where each severity comes from — Custom (this project), Org, or Default — and overridden rules can be reset back to the organization default.

Built-in rules

Routebase ships 57 built-in rules in five categories. Each rule has a default severity — Error, Warning or Info — which you can change per organization and per project; the tables below list the default.

Rules whose name says "must" are not automatically errors: severity and wording are set independently, so a rule can be named "must" and default to Warning.

Naming (8)

Rule	Default	Checks
Path parameters must use camelCase	Warning	Path parameter names (e.g., {userId}) should use camelCase naming convention.
Query parameters must use camelCase	Warning	Query parameter names should use camelCase naming convention.
Schema names must use PascalCase	Warning	Schema names should use PascalCase naming convention (e.g., 'UserProfile').
Schema properties must use camelCase	Warning	Object property names in schemas should use camelCase naming convention.
URL paths must follow the configured case convention	Warning	Path segments (excluding path parameters) must follow the configured naming convention (default: kebab-case). The convention is configurable.
Custom headers must use Train-Case	Info	Custom header parameter names should use Train-Case (e.g., 'X-Request-Id').
Enum values must use UPPER_SNAKE_CASE	Info	String enum values in schemas should use UPPER_SNAKE_CASE naming convention.
Operation IDs must use camelCase	Info	Operation IDs should use camelCase naming convention (e.g., 'getUsers').

Completeness (10)

Rule	Default	Checks
API must have a server URL	Warning	The API specification should define at least one server URL.
API must have a version	Warning	The API specification should define a version string.
Operations must have a description	Warning	Each endpoint should have a description explaining its purpose and behavior.
Operations must have a summary	Warning	Each endpoint should have a brief summary.
API must have a license	Info	The API specification should include a license identifier.
API must have contact information	Info	The API specification should include a contact email for consumers to reach out.
Parameters should have descriptions	Info	Each parameter should have a description explaining its purpose and expected values.
Responses must have a description	Info	Each response should have a description explaining what it represents.
Schemas must have a description	Info	Each schema should have a description explaining what data it represents.
Tags should have descriptions	Info	Each endpoint tag should have a description to document the group's purpose.

Best practices (19)

Rule	Default	Checks
Operation IDs must be unique	Error	Each operation ID must be unique across all endpoints in the specification.
Path parameters must be declared	Error	Each {parameter} in the path must have a corresponding parameter definition with 'in: path'.
Paths must be unique	Error	Two endpoints on the same method must not address the same route. OpenAPI ignores the
Paths must not have empty segments	Error	Paths must not contain double slashes or empty segments (e.g., '/users//profile').
Server URL must match URL-path versioning pattern	Error	When using URL-path versioning, server URLs should include a version prefix (e.g., /v1).
Deprecated versions should have a sunset date	Warning	Deprecated API versions should define a sunset date to inform consumers when the version will be removed.
Operation IDs must be valid in URLs	Warning	Operation IDs must contain only alphanumeric characters, dots, hyphens, and underscores to be safely used in URLs.
Operation tags must be defined	Warning	Tags used on operations must be defined in the specification's global tags list.
Paths should not end with a trailing slash	Warning	Paths should not have a trailing slash (e.g., '/users/' should be '/users').
Schema references must resolve	Warning	Every $ref in a schema must point to a schema that exists in this specification.
Server URL must not be example.com	Warning	The server URL should be a real API endpoint, not a placeholder like example.com.
Success responses should return an object, not a bare array	Warning	Top-level API responses should be JSON objects for extensibility, not bare arrays.
Tag names must be unique	Warning	Each tag name must be unique within the specification to avoid ambiguity.
Endpoints should define error responses	Info	Each endpoint should define at least one error response (4xx or 5xx) or a default response.
Error responses should use application/problem+json	Info	4xx and 5xx responses should use the RFC 7807 Problem Details format (application/problem+json).
List endpoints should have pagination parameters	Info	GET endpoints that return collections should include pagination query parameters.
No unused schema components	Info	Schemas defined in components should be referenced by at least one endpoint or other schema.
Published versions should have aliases	Info	Published API versions should have human-readable aliases (e.g., 'v1') for easier consumer adoption.
Versioning strategy should be configured	Info	API specifications should have a versioning strategy configured to enable consistent version management.

Security (10)

Rule	Default	Checks
Descriptions must not contain eval()	Error	Description fields must not contain eval() calls which could be exploited for XSS in rendered API documentation.
Descriptions must not contain script tags	Error	Description fields must not contain