Parameters

Parameters renders a table of inputs for an endpoint, such as query string values, path segments, headers, cookies, or body fields. Each parameter can carry a type, whether it’s required, a default and example value, and more. It also doubles as a general schema table: give it a Schema name and other Parameters blocks can link to it from their Links to schema field, which is how a nested object type points to its own field list elsewhere on the page.

Adding the block#

1. In the block editor, open the block inserter and search for Parameters.
2. Add it to the page, usually under an Endpoint block.
3. Give the table a title, e.g. Query Parameters or Request Body.
4. Click + Add parameter for each field, and fill in its settings.

Settings#

Table-level:

Setting	What it does
Table title	Heading shown above the table, e.g. Query Parameters.
Schema name (optional)	Makes this table a link target. Other Parameters blocks can point their Links to schema field at this name.

Per parameter (and per nested field):

Setting	What it does
Name	The parameter’s name.
Type	e.g. string, number, boolean, object.
Links to schema (optional)	Points to another Parameters block’s Schema name, for an object-type parameter with its own field list defined elsewhere.
Location	Query string, Path, Header, Cookie, or Body.
Format (optional)	e.g. int64, uuid, date-time.
Default value (optional)	Value used when the parameter is omitted.
Example value (optional)	A realistic sample value, separate from the default.
Allowed values (optional)	Comma-separated list of accepted values.
Minimum / Maximum (optional)	A numeric range, or min/max string length.
Pattern (optional)	A regular expression the value must match.
Required	Marks the parameter as required.
Nullable	Allows a null value.
Read-only	Only appears in responses.
Write-only	Only accepted in requests, e.g. a password field.
Deprecated	Flags the parameter as deprecated.
Description	Explanation shown in the table.

Any parameter can also carry nested fields, for an object-type parameter with its own inner structure (an address parameter with its own line1, city, and so on). Each nested field has the same set of settings as a top-level parameter.

Example#

A single query parameter: Table title set to Query Parameters, with one row: Name limit, Type integer, Location Query string, Default value 20, Description Max number of results to return.

The block#

In the editor, this is the Parameters block’s settings panel with the table title and one parameter row filled in as above, no code required.

The shortcode#

The same block, added as a shortcode instead, for a widget, classic-editor content, or a page builder that only accepts shortcodes. Because parameters is a list of parameter objects, it’s passed as a JSON string:

[nahnu_code_block block="parameters" title="Query Parameters"]
[{"name":"limit","type":"integer","location":"query","default":"20","description":"Max number of results to return."}]
[/nahnu_code_block]

The parameters attribute is wrapped in single quotes, with the strings inside it in double quotes, since that attribute is itself a double-quote-free JSON string. Keeping the quote characters distinct like this is what keeps the shortcode from cutting off early.

How it renders#

A table titled “Query Parameters” with one row: limit, type integer, location query, default 20, and the description text.

Tips#

• Give a table a Schema name whenever you expect to reuse it, then point other parameters at it with Links to schema instead of retyping the same fields.
• Use nested fields for an object-type parameter with its own inner structure, rather than flattening it into separate top-level parameters.
• Set both a default and an example value when they differ. The default is what happens if the field is omitted, the example is a realistic value someone would actually send.