Component
Docs
Priority
P2 - Medium (Would be helpful)
SDK Language(s)
No response
Feature Description
Fern currently auto-expands the top-level object in an API response, which is helpful for making response schemas easier to understand at a glance.
However, some of our public API responses use a wrapper object whose only meaningful property is another object, such as:
{
"resource": {
"id": "abc123",
"name": "Example"
}
}
In these cases, the top-level wrapper is expanded, but the actual resource remains collapsed. This means users still need to manually expand the response before seeing the fields they are most interested in.
It would be useful to support a configuration option that controls how many levels of a response schema are automatically expanded.
Ideally, this could be configured:
- Globally for the API documentation
- Per endpoint, to account for responses with different levels of nesting
This would improve the readability of APIs that consistently wrap resources in objects such as resource, data, or result, while still allowing documentation owners to avoid fully expanding deeply nested response schemas.
Any alternatives?
No response
Are you interested in contributing this feature?
Yes
Component
Docs
Priority
P2 - Medium (Would be helpful)
SDK Language(s)
No response
Feature Description
Fern currently auto-expands the top-level object in an API response, which is helpful for making response schemas easier to understand at a glance.
However, some of our public API responses use a wrapper object whose only meaningful property is another object, such as:
In these cases, the top-level wrapper is expanded, but the actual resource remains collapsed. This means users still need to manually expand the response before seeing the fields they are most interested in.
It would be useful to support a configuration option that controls how many levels of a response schema are automatically expanded.
Ideally, this could be configured:
This would improve the readability of APIs that consistently wrap resources in objects such as resource, data, or result, while still allowing documentation owners to avoid fully expanding deeply nested response schemas.
Any alternatives?
No response
Are you interested in contributing this feature?
Yes