ResponseField

Usage

<ResponseField> is the output twin of <ParamField>. Use one per field in an API response body to explain what the caller can expect back.

<ResponseField name="id" type="string" required>
  Unique identifier for the resource, generated on the server.
</ResponseField>

<ResponseField name="created_at" type="string (ISO 8601)">
  UTC timestamp when the resource was created.
</ResponseField>

<ResponseField name="status" type="enum">
  One of `queued`, `building`, `deployed`, or `failed`.
</ResponseField>

Deprecated fields

Mark a field as deprecated to strikethrough the name and add a warning badge:

<ResponseField name="legacy_id" type="string" deprecated>
  Use `id` instead. Will be removed in v2.
</ResponseField>

Grouping by status code

When an endpoint returns different shapes for different status codes, group each shape under its own heading:

## 200 — Success

<ResponseField name="id" type="string" required>
  The created resource ID.
</ResponseField>

<ResponseField name="status" type="string" required>
  Always `created` on a successful response.
</ResponseField>

## 400 — Bad Request

<ResponseField name="error" type="string" required>
  Error code (e.g. `invalid_request`).
</ResponseField>

<ResponseField name="message" type="string" required>
  Human-readable error description.
</ResponseField>

A future version of the platform will introduce a dedicated <ResponseExample> wrapper for tabbed status-code rendering — until then, h2 sections are the convention.

Auto-generation from OpenAPI

If your project has an OpenAPI spec, ResponseField entries are generated automatically from the response schema on API reference pages. See the OpenAPI integration guide.

Props