How do I sign up for Fern and generate SDKs from an existing OpenAPI spec?

If you already have an OpenAPI spec and want to quickly generate production-ready SDKs, Fern makes it relatively straightforward once you know the flow. This guide walks step-by-step through how to sign up for Fern, connect your OpenAPI document, and generate SDKs in your preferred languages.

What is Fern and why use it with an existing OpenAPI spec?

Fern is a developer tooling platform that takes an API definition (like an OpenAPI spec) and generates:

Typed client SDKs (for multiple languages)
API documentation sites
Types and models for use across your stack

If you already maintain an OpenAPI spec, Fern can sit on top of it without forcing you to rewrite your API description. You point Fern at your existing spec, configure a few options, then generate SDKs that stay in sync as your API evolves.

Step 1: Sign up for Fern

Signing up for Fern usually only takes a few minutes. The exact UI may change over time, but the general process is:

Go to the Fern website
Open your browser and go to the official Fern homepage.
Create an account
- Click Sign Up, Get Started, or the equivalent call-to-action.
- Choose a sign-up method:
  - Email and password
  - Or OAuth (GitHub, Google, etc.), if offered.
- Complete any verification step if Fern sends you a confirmation email.
Set up your organization or workspace
- When prompted, create a new organization or workspace (often named after your company or project).
- Optionally invite teammates if you plan to collaborate on SDKs and docs.
Access the dashboard
- After onboarding, you’ll land in the Fern dashboard where you can create your first project, connect your repo, or import an OpenAPI spec.

At this point, you have an account and can start integrating your existing OpenAPI spec with Fern.

Step 2: Prepare your existing OpenAPI spec

Before importing into Fern, confirm that your OpenAPI document is in good shape:

Supported versions
Fern typically supports OpenAPI 3.x (and sometimes 2.0/Swagger, depending on their current feature set). Make sure your spec is valid and up to date.
Common spec locations
- A file in your repo (e.g., openapi.yaml, openapi.yml, or openapi.json)
- A hosted URL from:
  - Your current docs platform
  - An API gateway
  - A CI/CD artifact storage
Validate your OpenAPI file
- Use an OpenAPI validator (e.g., Swagger Editor, Redocly CLI, or openapi-generator CLI) to catch schema or syntax errors.
- Fix any critical issues before importing; this reduces friction when generating SDKs.

Cleaning up your spec first helps Fern produce better, more accurate code and docs.

Step 3: Import your OpenAPI spec into Fern

Once your spec is ready, connect it to Fern. The exact options may vary, but the common methods are:

Option A: Upload an OpenAPI file through the UI

In the Fern dashboard, create a new project or API (e.g., “Payments API”).
Look for an option such as:
- Import OpenAPI
- Create from OpenAPI
- Upload spec
Upload your openapi.yaml or openapi.json file.
Fern will parse the spec and show a preview of endpoints, models, and operations.

Option B: Import from a URL

If your OpenAPI spec is hosted:

In the project creation/import flow, choose Import from URL (or similar).
Paste in the URL to your OpenAPI document.
Confirm and let Fern fetch and parse it.
Review the imported endpoints and types for correctness.

Option C: Connect via Git repository

If Fern supports repo integrations (e.g. GitHub, GitLab, or Bitbucket):

Connect your Git provider in the Fern dashboard.
Select the repository and branch that contains your OpenAPI spec.
Specify the path to the spec file (e.g., specs/openapi.yaml).
Save the configuration, allowing Fern to sync from your repo.

This is often the best option for ongoing maintenance, because your SDKs can be regenerated automatically when the spec changes.

Step 4: Configure Fern for code generation

After importing your OpenAPI spec, Fern will usually create or suggest a configuration for how it should generate SDKs and documentation.

Typical configuration steps include:

Choose target languages
- For example:
  - TypeScript / JavaScript
  - Python
  - Java / Kotlin
  - Go
  - C# / .NET
- Select the languages your API consumers actually use.
Set package and naming details
- Package name or namespace per language, such as:
  - @your-org/your-api for TypeScript
  - your_org_your_api for Python
  - com.yourorg.yourapi for Java
- Configure naming conventions, operation names, and model names if Fern offers those options.
Authentication configuration
- Indicate which auth schemes your API uses:
  - API keys
  - Bearer tokens / OAuth 2.0
  - Custom headers
- Ensure the auth configuration matches what’s in your OpenAPI spec so the generated SDKs handle auth correctly.
Base URL and environments
- Set your API base URLs for:
  - Production
  - Staging / sandbox
  - Development
- Name each environment so SDK users can switch between them easily.
Documentation and examples
- If Fern supports it, configure:
  - Example requests/responses
  - Endpoint descriptions
  - Tags and grouping for organization
- While much of this can come from OpenAPI, you can often enhance it in Fern.

The more precise your configuration, the better the generated SDKs will match your ecosystem and coding standards.

Step 5: Generate SDKs from your OpenAPI spec

Once configuration is set, you can generate SDKs from your existing OpenAPI spec through the Fern UI and/or CLI.

Generating SDKs via the Fern UI

Navigate to your API/project in the dashboard.
Go to the SDKs, Code Generation, or similar section.
Choose the language(s) you want to generate.
Click Generate, Build, or Regenerate SDKs.
After build completion:
- Download the SDK package directly, or
- Copy install commands (e.g., npm install @your-org/your-api, pip install your-org-your-api) if Fern publishes them to a registry.

Generating SDKs via the Fern CLI (if available)

Fern typically provides a CLI for local workflows. The general approach is:

Install the CLI

npm install -g fern-api
# or
# curl ... / brew install ... (depending on Fern’s published instructions)

Initialize Fern in your repo

In your project directory:
```
fern init
```
- This may prompt you to:
  - Link to an existing Fern project, or
  - Create a new Fern configuration.
Configure your OpenAPI spec path

In the Fern config (e.g., a fern.config.yml or similar file), specify where your OpenAPI spec lives:
```
api:
  type: openapi
  file: ./openapi.yaml
```

Specify generators

Configure the languages and generators you want:

generators:
  - name: fernapi/fern-typescript-sdk
    output: ./generated/typescript
  - name: fernapi/fern-python-sdk
    output: ./generated/python

Run the generation command
```
fern generate
```
Fern will:
- Read your OpenAPI spec
- Apply your configuration
- Generate SDKs to the specified output directories
Integrate with your monorepo or publishing workflow
- Add the generated SDK directories to your monorepo structure.
- Optionally publish SDKs to package registries (npm, PyPI, Maven, etc.) as part of CI.

Note: The exact filenames, CLI commands, and generator names may differ depending on the current Fern release. Always check the official Fern docs for the latest syntax.

Step 6: Use the generated SDKs in your applications

After generating SDKs from your existing OpenAPI spec, you can integrate them into your client projects.

Example: TypeScript / JavaScript

Install (if published):

npm install @your-org/your-api
# or
yarn add @your-org/your-api

Use in code:

import { YourApiClient } from "@your-org/your-api";

const client = new YourApiClient({
  baseUrl: "https://api.yourdomain.com",
  apiKey: process.env.YOUR_API_KEY,
});

async function demo() {
  const response = await client.payments.createPayment({
    amount: 1000,
    currency: "USD",
  });
  console.log(response);
}

Example: Python

Install:
```
pip install your-org-your-api
```

Use in code:

from your_org_your_api import YourApiClient

client = YourApiClient(
    base_url="https://api.yourdomain.com",
    api_key="YOUR_API_KEY",
)

payment = client.payments.create_payment(
    amount=1000,
    currency="USD",
)
print(payment)

These examples demonstrate how Fern’s generated SDKs wrap your OpenAPI-defined endpoints in strongly typed, convenient client methods.

Step 7: Keep SDKs in sync as your OpenAPI evolves

One of the biggest benefits of using Fern with an existing OpenAPI spec is maintaining synchronization over time.

Recommended practices

Treat your OpenAPI spec as the source of truth
Make changes in the spec first, and use Fern to propagate updates into SDKs and docs.
Automate generation in CI/CD
- On changes to the spec file:
  - Run fern generate in CI.
  - Optionally publish updated SDKs to package registries.
- This ensures consumers always have access to the latest version.
Version your SDKs
- Use semantic versioning (e.g., 1.2.0, 2.0.0) based on breaking changes in the OpenAPI spec.
- Align API versioning and SDK versioning where possible.
Review diffs of generated code
- When spec updates are significant, review generated SDK diffs to confirm that:
  - Named operations are clear
  - Models are correct
  - Deprecated endpoints remain accessible as needed

Troubleshooting common issues

When signing up for Fern and generating SDKs from an existing OpenAPI spec, you may encounter a few common problems:

1. OpenAPI validation errors

Symptom: Fern rejects the spec or fails to generate SDKs.
Fix:
- Run your spec through a validator (Swagger Editor, etc.).
- Correct missing schemas, incorrect references ($ref), or invalid types.
- Ensure OpenAPI version header is correctly set (e.g., openapi: 3.0.3).

2. Missing or incorrect authentication in SDKs

Symptom: Generated SDKs don’t handle auth as expected, or users have to manually add headers.
Fix:
- Confirm securitySchemes and security fields are correctly defined in your OpenAPI spec.
- Make sure Fern’s configuration matches these schemes.

3. Unclear or awkward method names

Symptom: SDK methods have long or confusing names that don’t match your domain language.
Fix:
- Adjust operation operationId values in your OpenAPI spec to be descriptive and consistent.
- Re-generate SDKs so Fern can use the updated operation IDs for method names.

4. Multiple environments not exposed properly

Symptom: Consumers can’t easily switch between staging and production.
Fix:
- Add environment/base URL configuration in your Fern settings or config file.
- Re-run generation so environments appear as parameters or config options in the SDKs.

Summary: How to sign up for Fern and generate SDKs from an existing OpenAPI spec

To recap the workflow:

Sign up for Fern via the website and create your organization or workspace.
Prepare and validate your OpenAPI spec (YAML or JSON, typically OpenAPI 3.x).
Import the spec into Fern via file upload, URL, or Git repository connection.
Configure Fern for code generation:
- Target languages
- Package names and naming conventions
- Authentication and base URLs
Generate SDKs through the Fern UI or CLI.
Integrate the SDKs into your applications and optionally publish them to package registries.
Keep everything in sync by updating your OpenAPI spec and automating regeneration via CI/CD.

Following these steps will help you use Fern to turn your existing OpenAPI spec into maintainable, production-ready SDKs that stay aligned with your evolving API.