--- title: API reference components description: Parameters, response fields, badges and tables. --- Four components for documenting an interface by hand. Pages generated from an OpenAPI spec use these too — hand-written and generated pages share one vocabulary. ## `ParamField` The parameter's name. **Required** — this is the prop migrated content most often lacks. The parameter's type, as you want it displayed. Where the parameter goes. Marks the parameter as required. Default value when the parameter is omitted. Marks the parameter as deprecated. Example value shown in the field. Per-element dialect override. Prefer the project-wide `content.dialect` setting. ```mdx Maximum number of results to return. ``` If migrated MDX fails with `DS-S03` complaining that `name` is missing, the file is almost certainly written in another platform's dialect where `path` doubles as the name. Set `content.dialect` rather than rewriting every field. ## `ResponseField` The field's name. The field's type. Required here, unlike on `ParamField`. Default value. Marks the field as always present. Marks the field as deprecated. ## `Badge` Colour treatment. Shares its vocabulary with `Callout`. Renders without a filled background. Renders with a border. Children: inline content — the badge's text. Reed's `Badge` takes its label as children rather than as a `text` prop, and it accepts `intent`. ## `Table` Keeps the header row visible while scrolling. Adds a filter input. Splits rows into pages. Rows per page when pagination is on. Lets rows expand to reveal detail. Placeholder for the filter input. One component covers sticky, searchable, paginated and expandable tables through boolean props, rather than a family of separate components. Plain markdown tables still work and remain the right choice for a handful of rows.