Response Body

2 min readUpdated September 19, 2026

Response Body documents what an endpoint actually returns: one or more status codes, each with its own example response body, optional response headers, and an optional schema table a visitor can switch to instead of the raw example.

Adding the block#

In the block editor, open the block inserter and search for Response Body.
Add it to the page, usually under an Endpoint, Parameters, and Request/Response block.
Click + Add response for each status code you want to document.
For each one, set the status code, content type, and response body, and add headers or schema fields if you need them.

Settings#

Setting	What it does
Block title	Heading for the block. Defaults to “Response Body” if left blank.
Show line numbers	Adds line numbers to every response body example.
Returns	A short description shown above the list of responses.

Per response:

Setting	What it does
Status code	e.g. `200`, `201`, `404`.
Content type	e.g. `application/json`.
Response body	The example response for that status code.
Response headers (optional)	Any number of headers, each with a name (e.g. `Location`), a type, and a description.
Schema fields (optional)	Any number of fields, each with a name, type, whether it’s required, and a description. Adding at least one field turns on a Show Schema toggle for readers, so they can switch that response between the real example and a type-shape table.

Example#

One response: Status code 200, Content type application/json, with a short JSON body.

Response Body

Returns the resource if the request succeeded.

200 application/json

Show Schema

{
  "id": "123",
  "status": "ok"
}

Name	Type	Required	Description
`id`	string	Required	Unique identifier.
`status`	string	Required	Current status.

The block#

In the editor, this is one response row filled in with a status code, content type, and body, no shortcode needed.

The shortcode#

The same block, added as a shortcode instead, for a widget, classic-editor content, or a page builder that only accepts shortcodes. Since responses is a JSON array, it can never go in a quoted attribute (a JSON array always contains a ], and the shortcode parser stops at the first literal ] it finds, quoted or not). It goes between the opening and closing tags instead:

[nahnu_code_block block="response-body" title="Response Body"]
[{"status":"200","contentType":"application/json","body":"{\"id\": 42, \"name\": \"Ada Lovelace\"}"}]
[/nahnu_code_block]

Putting the JSON between the tags, rather than in a quoted attribute, is what keeps the shortcode from cutting off partway through.

How it renders#

A 200 badge with application/json, and the JSON body shown underneath, formatted and highlighted like any other code sample.

Tips#

Document every status code a caller is likely to see, not just the success case. A 404 or 422 response is often as useful to a reader as the 200.
Only add schema fields when the shape is worth showing separately from the example. A short, obvious body usually doesn’t need one.
Keep the response body itself as a real, valid example. It’s what most readers will copy and paste.