Parameters

Parameters are the inputs an endpoint accepts alongside its request body. Each parameter has a location that tells a client where to put the value, a type that describes its shape, and a flag for whether it's required.

Parameter locations

Location	Where it goes	Example
Path	Inside the URL itself, matching a {variable} in the endpoint path	/users/{id} → id
Query	After the ? in the URL	/users?role=admin → role
Header	An HTTP request header	X-Request-Id
Cookie	A cookie sent with the request	session_id

Path parameters are always required — the URL is meaningless without them. Routebase enforces this: switching a parameter's location to Path sets the required flag automatically. Query, header, and cookie parameters are optional unless you mark them required.

Path parameters stay in sync with the URL

Path parameters are detected automatically from {variable} placeholders in the endpoint path. Add {id} to the path and the id parameter appears in the table; remove it and the parameter is removed again. If a parameter about to be removed carries extra data — a description, format, example, or default value — Routebase asks first: the Remove Path Parameters dialog lists what would be lost, and you can choose Keep Parameters or Remove.

Adding a parameter

1. Open an endpoint and expand the Parameters section.
2. Click Add Parameter.
3. Set the Name, Location (Path, Query, Header, or Cookie), and Type.
4. Optionally add a Format, Description, Example, and Default Value, and toggle Required.

Type and format

Give every parameter a type — String, Integer, Number, Boolean, Array, or Object. You can refine a type with an optional Format hint such as int32, date-time, uuid, or email, which tells consumers and code generators exactly what to expect.

Add a Default Value for optional parameters and an Example to make your documentation concrete and your mock responses realistic. These live in the parameter's Advanced Settings popover in the table — a highlighted icon shows when advanced settings are configured.

Editing in the table

The parameter table is built for fast, inline editing:

• Double-click a row to edit it in place. Enter commits, Escape cancels.
• Arrow keys commit the current row and move to the parameter above or below; Tab on the last row's description creates a new parameter.
• Drag the handle at the left of a row to reorder parameters — the order you set is the order shown in your documentation.
• Right-click a row for the context menu: Add Parameter, Edit, Move Up, Move Down, and Delete.

Deleting a parameter asks for confirmation; the action cannot be undone.

Deprecating a parameter

When a parameter is being retired, open its advanced settings and check Deprecated. Consumers see the deprecation marker in your documentation while the parameter still works, giving them time to migrate.

Reusing parameters

Parameters that appear on many endpoints — a pagination PageSize, a tenant header, a cursor — can be defined once as a parameter component in the Components section of the sidebar and kept as the single source of truth for name, type, format, and defaults. Specs imported from OpenAPI keep their referenced ($ref) parameters as parameter components, and each component tracks which endpoints use it. See Components.

Permissions

Editing parameters requires specs:write (included in the Member role). On a published, locked version the parameter table is read-only — create a new version to make changes; see Versioning.

Related

• Endpoints — where parameters are defined
• Components — reusable parameter definitions
• Responses — the other half of the request/response contract
• Schemas — reusable structures for bodies and payloads