You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: fern/products/docs/pages/changelog/2025-10-17.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,4 +18,4 @@ Key features include:
18
18
19
19
The component is built with a modular architecture, making it maintainable and extensible for future enhancements.
20
20
21
-
To learn more about using Runnable Endpoints in your documentation, visit the [Runnable Endpoint docs](/learn/docs/building-and-customizing-your-docs/component-library/runnable-endpoint).
21
+
To learn more about using Runnable Endpoints in your documentation, visit the [Runnable Endpoint docs](/learn/docs/writing-content/components/runnable-endpoint).
description: 'Test API endpoints directly from your documentation with an interactive request builder.'
2
+
title: Runnable Endpoint
3
+
description: Test API endpoints directly from your documentation with an interactive request builder.
4
4
---
5
5
6
-
Runnable Endpoint is an interactive component that allows users to test API endpoints directly within your documentation. It provides a full-featured request builder with form inputs for headers, path parameters, query parameters, and request bodies, along with real-time response preview.
The Runnable Endpoint component automatically detects and loads endpoint definitions from your API specification. You can embed it in your documentation pages using the `<RunnableEndpoint>` component.
6
+
The `<RunnableEndpoint>` component enables users to make real HTTP requests to your APIs directly in the API Reference. It auto-detects endpoint definitions from your API specification and provides a request builder with inputs for headers, path parameters, query parameters, and request bodies.
All fields are collapsible for a cleaner interface when working with endpoints that have many parameters.
41
-
42
-
### Multiple Examples Support
43
-
44
-
When your endpoint has multiple pre-configured examples, the Runnable Endpoint component displays a dropdown selector in the header, allowing users to quickly switch between different example scenarios.
45
-
46
-
### Environment Selection
47
-
48
-
If your API defines multiple environments (production, staging, development), the component automatically displays an environment selector, making it easy for users to test against different base URLs.
49
-
50
-
### Request Execution
51
-
52
-
Users can send real HTTP requests to your API directly from the documentation. The component handles:
53
-
54
-
- Request construction with proper headers and authentication
55
-
- Real-time request/response preview
56
-
- Error handling and display
57
-
- Response status codes and timing
58
-
59
-
### Link to API Reference
60
-
61
-
The component includes an "Open in API reference" button that navigates users to the full API reference page for the endpoint, providing quick access to detailed documentation.
62
-
63
-
### Form State Persistence
64
-
65
-
Form inputs are automatically persisted in the browser's local storage, so users' test data is preserved even when navigating between pages or refreshing the browser.
23
+
The Runnable Endpoint supports:
24
+
-**Multiple examples** – When your endpoint has multiple pre-configured examples, the component displays a dropdown selector in the header so users can switch between different examples
25
+
-**Multiple environments** – If your API defines multiple environments (production, staging, development), the component automatically displays an environment selector so users can test against different base URLs
26
+
-**API Reference integration** – Each Runnable Endpoint includes a button that links users to the full API reference documentation for the endpoint
27
+
-**Real-time response preview** – Users can view response status, headers, body, and response time immediately after sending requests
28
+
-**Form persistence** – Form inputs are automatically persisted in the browser's local storage, so users' test data is preserved even when navigating between pages or refreshing the browser
66
29
67
30
## Properties
68
31
@@ -75,51 +38,5 @@ Form inputs are automatically persisted in the browser's local storage, so users
Optional CSS class name for custom styling of the component container.
41
+
CSS class name for custom styling of the component container.
79
42
</ParamField>
80
-
81
-
## Architecture
82
-
83
-
The Runnable Endpoint component is built with a modular architecture:
84
-
85
-
-**RunnableEndpointHeader**: Displays the endpoint URL, method, example selector, and navigation controls
86
-
-**RunnableEndpointFormSection**: Renders input forms for different parameter types (headers, path, query, body)
87
-
-**RunnableEndpointActions**: Provides action buttons for clearing the form and sending requests
88
-
-**RunnableEndpointResponseSection**: Displays the API response with syntax highlighting and formatting
89
-
90
-
This componentized structure makes the code easier to maintain and allows for future enhancements to individual sections without affecting others.
91
-
92
-
## Example with Custom Configuration
93
-
94
-
<Tabs>
95
-
<Tabtitle="Example">
96
-
```jsx
97
-
<RunnableEndpoint
98
-
endpoint="POST /api/users"
99
-
example="Create Admin User"
100
-
className="my-custom-runnable"
101
-
/>
102
-
```
103
-
</Tab>
104
-
<Tabtitle="Markdown">
105
-
````markdown
106
-
<RunnableEndpoint
107
-
endpoint="POST /api/users"
108
-
example="Create Admin User"
109
-
className="my-custom-runnable"
110
-
/>
111
-
````
112
-
</Tab>
113
-
</Tabs>
114
-
115
-
## Best Practices
116
-
117
-
1.**Use descriptive examples**: When defining multiple examples in your API specification, use clear, descriptive names that help users understand what each example demonstrates.
118
-
119
-
2.**Include authentication details**: Make sure to document any required authentication headers or tokens that users need to provide to successfully test endpoints.
120
-
121
-
3.**Provide meaningful example data**: Pre-populate examples with realistic data that demonstrates the full capabilities of your API.
122
-
123
-
4.**Test in multiple environments**: If you offer staging and production environments, make sure both are properly configured so users can safely test without affecting production data.
124
-
125
-
5.**Document expected responses**: While the component shows real responses, it's helpful to document what users should expect to see for successful requests.
0 commit comments