Build with Fern is a good shortlist candidate if an API spec needs to produce a portal and maintained client libraries. If your support team mostly needs help articles that stay current, you may not need that entire workflow. Make the decision with your actual API and your actual writers, not a demo spec.
DocsAlot publishes this buyer guide and competes in documentation and SDK generation. The examples below are version-specific public issue reports, not independently reproduced defects or a measure of how often Fern fails. This is Build with Fern, the API tooling vendor, not Ferndesk.
One spec can behave differently in the Explorer and SDK
In Fern issue #18268, a reporter showed an OpenAPI query parameter that accepted multiple values but appeared as a single selection in the Explorer. The report distinguishes the generated client from the browser interface. That's exactly the distinction to verify: a spec importing successfully doesn't prove a reader can send the intended request from the published docs.
Open an endpoint with repeated filters or unusual authentication in the trial. Check the network request against a known-good example. If the Explorer can't send the right shape, decide whether a working code example is an acceptable fallback for your users.
Treat generated clients as code you have to ship
Issue #18373 reports a TypeScript client sending different JSON property names in a multipart request than in an ordinary JSON request. The issue includes a reproduction and generator version. It doesn't show that standard JSON or all languages are affected.
Generate the package, install it in a separate sample app, and test authentication, pagination, errors, and an upload against a sandbox. Inspect what goes over the wire. Fern documents both managed and self-hosted SDK generation; pick the deployment and ownership model your team can actually maintain.
Make the preview a release test
Issue #18518 describes a local preview that did not render with a particular CLI version. Run a fresh clone on the current version you intend to pin, change a guide and an API operation, and preview both before merge. Keep the last known-good build available.
Choose Fern if the generated outputs work for your API and justify the extra workflow. If a support lead is the main author and SDKs aren't the buying reason, start with a branded help center. For the API-oriented comparison, see DocsAlot vs. Fern and use the same smoke test on both.