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

If you already have an OpenAPI specification and you’re exploring Fern for SDK generation, you’re in a great position to move quickly. Fern can take your existing OpenAPI spec and turn it into high-quality, language-specific SDKs with versioning, publishing, and documentation support—all with a relatively simple setup.

This guide walks through how to sign up for Fern, connect your OpenAPI spec, and generate SDKs, step by step.

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

Fern is an API platform that helps you:

Turn OpenAPI specs into SDKs in multiple languages
Keep SDKs in sync with your API schema
Auto-publish client libraries to package registries (npm, PyPI, Maven, etc.)
Generate documentation and typed clients for faster integration

If you already invested in a clean OpenAPI description of your API, Fern lets you reuse that work instead of rebuilding schemas from scratch.

Step 1: Sign up for Fern

1.1 Create your Fern account

Go to the Fern website (typically buildwithfern.com).
Click Sign Up or Get Started.
Choose your sign-up method:
- GitHub account (common for engineering teams)
- Email and password
- Other OAuth options if available
Confirm any email verification if prompted.

You now have a Fern account where you can manage organizations, projects, SDKs, and CI integrations.

1.2 Create or join an organization

After signup, Fern usually prompts you to:

Create a new organization for your company or project (e.g., acme-api), or
Join an existing organization if you were invited.

Your organization is where you’ll manage:

API definitions and specs
SDK generation pipelines
Publishing tokens and secrets
Team members and permissions

Name your organization clearly so other developers can easily identify it.

Step 2: Prepare your existing OpenAPI spec

Before importing your spec into Fern, make sure it’s in good shape:

2.1 Supported formats and locations

Fern typically supports:

OpenAPI 3.x (JSON or YAML)
OpenAPI files stored:
- In your repository (e.g., openapi.yaml or openapi.json)
- In a dedicated API repo (mono- or multi-repo)
- Hosted at a URL (e.g., https://api.example.com/openapi.yaml)

Confirm:

The spec is accessible (no auth required if using a URL, or you’ll need repo access)
The document is valid YAML/JSON and parses correctly

2.2 Validate your OpenAPI spec

Before importing it, validate your spec using:

swagger-cli validate openapi.yaml
Online OpenAPI validators (e.g., Swagger Editor, Redocly)
CI checks already in your project

Fix common issues such as:

Missing or duplicate operation IDs
Unresolved $ref paths
Invalid schema types or formats
Incomplete components/schemas

A clean spec ensures Fern can correctly generate and type your SDKs.

Step 3: Create a new Fern project from your OpenAPI spec

There are generally two flows:

CLI-based setup, ideal if you prefer Git-based, codified configuration.
Dashboard-based setup, ideal if you want a guided UI experience.

3.1 Install the Fern CLI (recommended)

On your local machine:

npm install -g fern-api
# or
yarn global add fern-api

Verify installation:

fern --version

If the CLI requires login, run:

fern login

and authenticate using your browser or Fern credentials.

3.2 Initialize a Fern workspace

In your repository (or a new project folder):

mkdir fern && cd fern
fern init

The CLI will ask:

Your organization name (matching the org you created in the dashboard)
The type of project:
- From OpenAPI spec
- From scratch or Fern definition

Choose the option to create a project from an existing OpenAPI spec.

You’ll then be prompted to:

Provide the path to your openapi.yaml or openapi.json, or
Provide the URL to the hosted OpenAPI spec

The CLI will scaffold:

A fern/ directory (or similar) with configuration files
A fern.config.json or fern.json that references your OpenAPI spec
Language-target configuration placeholders for SDKs

3.3 Set up via the Fern dashboard (alternative)

If you prefer the UI:

In the Fern dashboard, go to APIs or Projects.
Click Create project or Add API.
Choose Import from OpenAPI.
Upload your spec file or paste a spec URL.
Confirm the import and mapping.

The dashboard will often show you an overview of your endpoints and schemas derived from the OpenAPI definition.

Step 4: Configure Fern to generate SDKs

With your OpenAPI spec connected, you need to configure how Fern should generate SDKs.

4.1 Understand the Fern config

Your Fern configuration may include files like:

fern.json (root config)
generators.yml or generators.json (SDK generator definitions)
Additional configuration files for docs, examples, and codegen behavior

Open the generator configuration file and review the structure. A typical configuration might look like:

generators:
  - name: fernapi/fern-typescript-node-sdk
    version: 0.10.0
    output:
      location: local-file-system
      path: ../sdks/typescript
    config:
      packageName: "@acme/api-client"
      publish:
        npm:
          registryUrl: "https://registry.npmjs.org"
  - name: fernapi/fern-python-sdk
    version: 0.9.0
    output:
      location: local-file-system
      path: ../sdks/python
    config:
      packageName: "acme_api_client"

The exact syntax may vary based on Fern’s current version, but the concepts are similar.

4.2 Select target languages

Common Fern generators include (names may vary):

TypeScript / JavaScript SDK
Python SDK
Java / Kotlin SDK
Go SDK
C# SDK

In your generator configuration:

Add a block for each language you want.
Point the output.path to where the generated SDK should live.
Configure the package name and options for that language.

Example for a TypeScript SDK:

- name: fernapi/fern-typescript-node-sdk
  version: 0.10.0
  output:
    location: local-file-system
    path: ../sdks/typescript
  config:
    packageName: "@acme/sdk"
    namespaceExport: "Acme"

4.3 Configure publishing (optional but recommended)

Fern can automatically publish your SDKs when you run generators in CI.

For each language:

Configure registry settings:
- npm for TypeScript/JS
- PyPI for Python
- Maven Central or GitHub Packages for Java
- NuGet for .NET
Add auth tokens as environment variables in your CI, not in config files.

Example for Python:

config:
  packageName: "acme_sdk"
  publish:
    pypi:
      repositoryUrl: "https://upload.pypi.org/legacy/"

Your CI pipeline will then inject credentials like PYPI_USERNAME and PYPI_PASSWORD or appropriate tokens.

Step 5: Run Fern to generate SDKs from your OpenAPI spec

Once configuration is done, you can generate SDKs locally.

From your Fern workspace:

fern generate

This command:

Pulls your OpenAPI spec (from file or URL)
Applies Fern configuration
Runs the specified generators
Writes SDK code to the configured output directories

Check the generated SDK:

Confirm all endpoints appear
Ensure type definitions match your OpenAPI schemas
Inspect any README or usage examples that Fern added

If you see errors:

Read the CLI output for validation failures or generator issues
Fix your OpenAPI spec or generator config and re-run fern generate

Step 6: Integrate SDK generation into CI/CD

To keep SDKs always in sync with your API changes, add Fern to your CI pipeline.

6.1 Add a CI job

Example (GitHub Actions):

name: Generate SDKs

on:
  push:
    branches:
      - main

jobs:
  generate-sdks:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Fern CLI
        run: npm install -g fern-api

      - name: Generate SDKs
        run: fern generate

      # Optional: commit generated SDKs back to repo or trigger separate publish jobs

Adjust according to your CI platform (GitLab CI, CircleCI, Jenkins, etc.).

6.2 Optional: Automatic SDK publishing

You can extend CI to:

Run tests for each generated SDK
Publish to package registries when:
- A new tag is pushed (e.g., v1.2.0)
- A release branch merges
- A version file is updated

Typical workflow:

Generate SDKs with fern generate.
Run language-specific tests (e.g., npm test, pytest).
Publish using Fern’s capabilities or language-native publishing commands, with credentials stored as CI secrets.

Step 7: Use the generated SDKs in your applications

Once your SDKs are generated and optionally published:

7.1 Install the SDK

For example, a TypeScript SDK:

npm install @acme/sdk
# or
yarn add @acme/sdk

Python:

pip install acme-sdk

Java (Gradle):

implementation "com.acme:api-client:1.0.0"

7.2 Initialize the client

Your usage will depend on the generator, but typically:

TypeScript example:

import { AcmeClient } from "@acme/sdk";

const client = new AcmeClient({
  apiKey: process.env.ACME_API_KEY,
  baseUrl: "https://api.acme.com",
});

const response = await client.orders.createOrder({
  itemId: "item_123",
  quantity: 2,
});

Python example:

from acme_sdk import AcmeClient

client = AcmeClient(
    api_key=os.environ["ACME_API_KEY"],
    base_url="https://api.acme.com"
)

order = client.orders.create_order(
    item_id="item_123",
    quantity=2
)

Check the generated SDK’s README or Fern documentation for the exact client names and configuration options.

Best practices when generating SDKs from an existing OpenAPI spec

To get the most out of Fern:

Maintain a single source of truth
Keep your OpenAPI spec in version control and treat it as the canonical API contract.
Use consistent operation IDs
Operation IDs often map to method names in SDKs. Make them descriptive and stable.
Add examples to your OpenAPI spec
Request/response examples in OpenAPI can propagate into SDK documentation and improve developer experience.
Version your API and SDKs together
Align breaking changes in your API with major version bumps in your SDKs.
Automate everything
From spec validation to SDK generation and publishing, embed Fern into CI so human error is minimized.

Troubleshooting common issues

SDK missing endpoints

Check that all paths in your OpenAPI spec are under paths.
Ensure no syntax errors are causing partial parsing.
Confirm there are no filters or exclusions in your Fern generator config.

Type mismatches or incomplete types

Validate schemas under components/schemas.
Avoid ambiguous any-like definitions where possible.
Use clear oneOf / anyOf / allOf structures and document them.

Authentication not working in the SDK

Ensure security schemes (e.g., apiKey, bearerAuth) are defined under components/securitySchemes.
Set a global security section or per-operation overrides.
Check Fern’s documentation for how authentication is mapped into SDK configuration options.

Summary

To sign up for Fern and generate SDKs from an existing OpenAPI spec, follow this flow:

Sign up for Fern and create or join an organization.
Prepare and validate your OpenAPI spec (YAML/JSON, v3 preferred).
Initialize a Fern project via CLI or dashboard and import your spec.
Configure generators for your target languages and output locations.
Run fern generate to produce SDKs locally.
Integrate into CI/CD for automated, consistent SDK updates and publishing.
Use the SDKs in your applications and keep your OpenAPI spec as the source of truth.

By pairing your existing OpenAPI spec with Fern’s generators, you can streamline SDK production, keep clients always in sync with your API, and deliver a much smoother experience for both internal and external developers.