speakeasy-api/speakeasy

Speakeasy CLI - Enterprise developer experience for your API

Enterprise-Ready Developer Experience for your REST API

Launch production-quality SDKs, Terraform providers, docs, and more in minutes 🚀

What is Speakeasy?

Speakeasy gives your users the developer experience that makes API integrations easy.

Don't put the burden of integration on your users. Take your APIs to market with best-in-class, enterprise-ready SDKs, Terraform providers, SDK docs, and more.

Key Features

• LLM Powered API Maintenance - Keep your API schema up to date and follow best practices with automatic maintenance powered by best-in-class LLMs. Try it out now in the CLI with speakeasy suggest or embed it into your GitHub workflow using our action.
• Production-Quality SDKs - Ergonomic, type-safe, and fault-tolerant client libraries built for production use cases with idiomatics optimized for each language. Embed additional capabilities like auth, retries, pagination, and more using spec-based extensions.
• Production-Quality Terraform Providers - Expose your API for infrastructure-as-code use cases with fully featured Terraform providers.
• SDK Docs - Markdown usage snippets for every single operation and model in your SDK. Export usage snippets and host them on a branded SDK and API docs site using our Docusaurus React plugin.
• Distribution to Package Managers - A complete pipeline for distributing your libraries to popular package managers like npm, PyPI, Maven, and Terraform Registry.
• Supports Open Standards - Speakeasy works with your existing API framework by supporting OpenAPI3.X and other open standards. Plug and play not rip and replace.

For upcoming features and bug fixes, check out our public roadmap.

What is the Speakeasy CLI?

The Speakeasy CLI is a tool for interacting with the Speakeasy platform that brings the functionality of Speakeasy into your development workflow.

You can run the Speakeasy CLI locally or in your CI/CD pipeline to validate your API specs, generate SDKs, and more. Looking to embed this into your GitHub CI/CD? Check out these docs instead.

Here are a few key functions of the CLI:

• generate - Generate idiomatic client SDKs from your API specs.
• validate - Validate the correctness of your API specs. The CLI has a built-in command to validate your spec for SDK readiness and post helpful error messages.
• suggest - Use an LLM to autocorrect your spec validation failures.
• merge - Work with your existing documentation workflows by merging your API specs into a single spec.
• auth - Authenticate with the platform and manage API keys.

For a complete list of commands check out our reference or type speakeasy and our interactive mode will take you through the available functions.

Design Choices

Each SDK generated by Speakeasy is idiomatic to the language it's generated for while sharing common patterns with SDKs for other languages to allow for switching between them. Using shared patterns also helps to keep the Speakeasy generation engine efficient while supporting many languages.

Here are some of the Speakeasy design decisions:

• Each SDK generally implements a base SDK class that contains the methods for each of the API endpoints defined in the OpenAPI document.
• Where possible, Speakeasy generates fully typed models from the OpenAPI document, separating models defined as components in the docs from models defined in line with operations.
• Based on the configuration in the OpenAPI document, Speakeasy annotates types using reflection metadata to determine how to serialize and deserialize them.
• To get SDKs to your end users quickly, Speakeasy generates full packages for each language that you should be able to publish to a package registry with little additional work. If you're interested in having a managed pipeline to your package manager, check out the Speakeasy Generation GitHub Action.

Want to learn more about the Speakeasy methodology? Take a look at how the Speakeasy SDK generator compares to OSS options.

If you're interested in generating managed GitHub repos for your SDKs or enterprise support, reach out to us or schedule a chat. We'd love to help you build out API DevEx.

If you're interested in having managed GitHub repos generated for your SDKs or enterprise support, reach out to us or schedule a chat. We'd love to help you build out API DevEx.

Speakeasy may capture metadata on usage of the Speakeasy CLI to better understand OpenAPI features so that we can build better code generators and other tools over time.

Installation

Homebrew (macOS and Linux)

brew install speakeasy-api/homebrew-tap/speakeasy

Script (macOS and Linux)

curl -fsSL https://raw.githubusercontent.com/speakeasy-api/speakeasy/main/install.sh | sh

Chocolatey (Windows)

choco install speakeasy

Manual Installation

Download the latest release for your platform from the releases page, extract, and add the binary to your path.

Keeping Up to Date

The CLI will warn you if you're running an outdated version. To update the CLI run:

speakeasy update

Alternatively, install the latest version via your package manager.

Getting Started With the Speakeasy CLI

Once you have installed the Speakeasy CLI, you can verify it's working by running:

speakeasy --help

See the Speakeasy docs for how to get started with the Speakeasy CLI.

Authenticating the Speakeasy CLI

The Speakeasy CLI depends on Speakeasy Platform APIs. Connect your Speakeasy CLI with the Speakeasy Platform by running:

speakeasy auth login

You'll be redirected to a login URL to select an existing workspace or create a new workspace on the platform. If your local network prevents you from accessing the login page prompted by the CLI, you can log in manually at app.speakeasyapi.dev, retrieve an API key, and populate a local environment variable named SPEAKEASY_API_KEY with the key.

SDK Generation

Command:

speakeasy generate sdk [flags]

Options:

  -b, --baseurl string   base URL for the API (only required if OpenAPI spec doesn't specify root server URLs)
  -d, --debug            enable writing debug files with broken code
  -h, --help             help for SDK
  -l, --lang string      language to generate SDK for, defaults to go (available options: go, python, typescript, java)
  -o, --out string       path to the output directory
  -s, --schema string    path to the OpenAPI schema
  -y, --auto-yes string  auto answer yes to all prompts

Take a look at the Speakeasy getting started page for in-depth information.

Schema Validation

Note that you don't need to be logged in to the Speakeasy platform to validate your API schema.

Command:

speakeasy validate openapi [flags]

Options:

  -h, --help            help for OpenAPI
  -s, --schema string   path to the OpenAPI schema

OpenAPI Usage

Note that you don't need to be logged in to the Speakeasy platform to view OpenAPI usage information.

Command:

Use the following command to return usage information for a given OpenAPI schema to a CSV. Usage information includes counts of OpenAPI features.

speakeasy usage [flags]

Options:

  -d, --debug         enable writing debug files with broken code
  -f, --file string   path to file to generate usage information for
  -h, --help          help for usage
  -o, --out string    path to output file

OpenAPI Support

The tables below give an overview of what we support from OpenAPI.

✅ Server Configuration

Name	Notes	Swagger Link	Support
ServerURL config	Global and per-method (include base URL and templating)	api-host-and-base-path	✅
Authentication and security	Global and per-method	authentication	✅
Method generation			✅
Model generation	Request and response		✅

⚠️ Path Parameters Serialization (path-parameters)

Name	Notes	Swagger Link	Support
Default	(style = simple, explode = false)	serialization/#path	✅
Basic types			✅
Simple objects			✅
label			❌
matrix			❌

⚠️ Query Parameters Serialization (query-parameters & query)

Name	Notes	Swagger Link	Support
json			✅
form			✅
spaceDelimited			✅
pipeDelimited			✅
deepObject			✅
Basic types			✅
Simple objects			✅

✅ Request Headers (header)

Name	Notes	Swagger Link	Support
Simple (explode = true)			✅
Simple (explode = false)			✅

⚠️ Request Body Serialization

Name	Notes	Swagger Link	Support
Multipart encoding		multi-part requests	✅
Binary			✅
Form data			✅
JSON	Both application/json and text/json		✅
x-www-form-urlencoded	Including encoding, but not non-object types	describing-request-body	⚠️
Plain text			✅
Raw byte			✅
Handling required body			✅
XML			❌
Other media types			❌

⚠️ Response Body Deserialization

Name	Notes	Swagger Link	Support
Return StatusCode and Content-Type			✅
JSON			✅
Plain text			✅
Raw byte			✅
JSON			✅
Other media types			❌

✅ Media-Type Patterns (media-types)

✅ Datatypes

Name	Notes	Swagger Link	Support
Basic types		data-models/data-types	✅
Enums			✅
Number formats	float, double, int32, int64		✅
Date-time			✅
Binary			✅
Arrays			✅
Objects			✅
Optional			✅
Maps			✅
Any type			✅
OneOf/AnyOf/AllOf	anyOf treated as oneOf	oneof-anyof-allof-not	✅

✅ Miscellaneous

Name	Notes	Swagger Link	Support
Auxiliary files*			✅
x-speakeasy-server-id generation			✅
Snippet generation			✅
README generation			✅
Documentation generation			✅

* Utility classes and functions to help with serialization and deserialization.

* Files needed for creating a fully compilable package that can be published to the relevant package manager without further changes.

Advanced Generation Features

• SDK Gen Configuration - Learn how to configure the SDK generator to your needs.
• Generated Comments - Learn how comments are generated from your OpenAPI document and how to customize them.
• Configuring the SDK with Server URLs - Learn how to configure the SDK to use different server URLs for different environments.
• Readme Generation - Learn how the SDK generates README.md files and how to control this.
• Using Custom HTTP Clients With the SDK - Learn how to provide a custom HTTP Client to the SDKs at runtime.
• Capturing Telemetry on SDK Usage - Learn how you can capture telemetry to get an understanding of how your SDKs are being used.
• Automated SDK Generation - Use our GitHub Action and Workflows to set up CI/CD for generating and publishing your SDKs.
• Override Generated Names - Speakeasy uses your OpenAPI schema to infer names for class types, methods, and parameters. However, you can override these names to tailor the generated SDK to your preferences.
• Add Retries to Your SDKs - The generator supports the ability to generate SDKs that will automatically retry requests that fail due to network errors or any configured HTTP status code.

Getting Support

If you need support using the Speakeasy CLI, please contact us via email, on Slack, or file a GitHub issue and we'll respond ASAP!

Usage

speakeasy [flags]

Options

  -h, --help   help for speakeasy

Sub Commands

• speakeasy api - Access the Speakeasy API via the CLI
• speakeasy auth - Authenticate the CLI
• speakeasy generate - Generate Client SDKs and Terraform Providers
• speakeasy validate - Validate OpenAPI documents

CLI

speakeasy

The speakeasy cli tool provides access to the speakeasyapi.dev toolchain

Details

A cli tool for interacting with the Speakeasy https://www.speakeasyapi.dev/ platform and its various functions including: - Generating Client SDKs from OpenAPI specs (go, python, typescript, java, php, c#, swift, ruby, terraform) - Validating OpenAPI specs - Interacting with the Speakeasy API to create and manage your API workspaces - Generating OpenAPI specs from your API traffic - Generating Postman collections from OpenAPI Specs

Usage

speakeasy [flags]

Options

  -h, --help              help for speakeasy
      --logLevel string   the log level (available options: [info, warn, error]) (default "info")

Sub Commands

• speakeasy ask - Starts a conversation with Speakeasy trained AI
• speakeasy auth - Authenticate the CLI
• speakeasy bump - Bumps the version of a Speakeasy Generation Target
• speakeasy configure - Configure your Speakeasy SDK Setup.
• speakeasy generate - One off Generations for client SDKs, docsites, and more
• speakeasy lint - Lint/Validate OpenAPI documents and Speakeasy configuration files
• speakeasy merge - Merge multiple OpenAPI documents into a single document
• speakeasy openapi - Utilities for working with OpenAPI documents
• speakeasy overlay - Work with OpenAPI Overlays
• speakeasy quickstart - Guided setup to help you create a new SDK in minutes.
• speakeasy run - generate an SDK, compile OpenAPI sources, and much more from a workflow.yaml file
• speakeasy suggest - Validate an OpenAPI document and get fixes suggested by ChatGPT
• speakeasy update - Update the Speakeasy CLI to the latest version

speakeasy's Issues

Unity Support for SDK Generation

Swift (ios) Support for SDK Generation

[SPE-2009] Publish the docs folder

1. Publish the docs folder.

Edit: removed exports mechanism for directly exposing models subpaths from scope. Argumentation:

1. It appeared to have divergent behaviour based on ESM / Node / Old-Versions-Of-Node when attempting to import modules. We needed a "./*": "./*"passthrough to not break existing references.
2. When looking through other large SDKs, it appears that most of them made the same conclusion, and usually just use exports to limit the set of files exported: not to do path rewriting.

An ideal view would instead be import {MyModelType} from 'my-sdk', or explicit models at specific subpaths like import {MyModelType} from 'my-sdk/models/shared'(for scenarios where they might have conflicting names). The most compliant way of doing this would appear to be having an index.js / index.d.ts file located at the relative subpath of the package.json, rather than using path-rewriting mechanisms.

Instead, will be pushing a set of namespaced model types to the default export level in a different effort.

_{From SyncLinear.com | SPE-2009}

[SPE-1799] Monkey Patching support using .genignore file for SDK overrides

_{From SyncLinear.com | SPE-1799}

See the internal RFC document for discussion and comments that might helpful in making decisions. The work that should be done is:

• Use the existing code for parsing the root .genignore and rework or copy it to check the ignore matcher when writing to files whether generated via template or copied.
• Ensure that ignored files do not end up in files.gen
• A .genignore file should also never appear in files.gen

Nice to haves (followup tickets if not implemented here):

• A command-line option to speakeasy generate sdk that puts all files that would have been generated but were ignored into a special directory. Suggest the option be named -genignore-dir.
• Analytics for counting files ignored by type (e.g., modelfile versus auxiliary versus usage-example, etc.) or by the gitignore pattern matched or both.

_{From SyncLinear.com | SPE-1799}

Allow to set a required param to null in Go and Terraform

For some API, we may need to set id=null in the Request body to create a resource.

Currently it is not achievable as setting id property in OpenAPI schema :

      required:
        - id
        - environment_id
        - account_id
        - project_id
        - name
        - dbt_version
        - triggers
        - schedule
        - settings
        - execution
        - state
        - generate_docs
        - run_generate_sources
      properties:
        id:
          type: integer
          nullable: true
          default: null

When instanciating the TF resource:

resource "foo" "bar" {
  id         = null
  name       = "test_terraform"
  account_id = 22219
}

We end up with the following error : Must set a configuration value for the id attribute as the provider has marked it as required.

Getter functions for Golang

[SPE-1855] CLI generated file permissions preventing gradle from running

null

_SPE-1855

[SPE-1878] SDK reference documentation

SDK Docs.pdf

_{From SyncLinear.com | SPE-1878}

[SPE-1804] Typescript SDK is getting errors on the `headers` object for an "implicit any" warning

_{From SyncLinear.com | SPE-1804}

[SPE-1886] Terraform provider generation : issue with mixed types params using anyOf

Hey team,

Trying to generate a TF provider for Hightouch API.

For the Update Sync endpoint (See doc here, schedule can be one of several structures.

In their OpenAPI file it looks like this :

schedule:
  properties:
    schedule:
      anyOf:
      - "$ref": "#/components/schemas/IntervalSchedule"
      - "$ref": "#/components/schemas/CronSchedule"
      - "$ref": "#/components/schemas/VisualCronSchedule"
      - "$ref": "#/components/schemas/DBTSchedule"
    type:
      type: string
  required:
  - schedule
  - type
  type: object
  nullable: true

SpeakEasy generates files well but when running tfplugindocs, it detects an error :

internal/provider/sync_resource.go:349:22: invalid operation: data.Schedule != nil (mismatched types SyncCreateSchedule and untyped nil)

The linked part within go file :

configuration := make(map[string]interface{})
// Warning. This is a map, but the source tf var is not a map. This might indicate a bug.
destinationID := data.DestinationID.ValueString()
disabled := data.Disabled.ValueBool()
modelID := data.ModelID.ValueString()
var schedule1 interface{}
var intervalSchedule *shared.IntervalSchedule
if data.Schedule != nil {
   quantity, _ := data.Schedule.Quantity.ValueBigFloat().Float64()
   unit := shared.IntervalUnit(data.Schedule.Unit.ValueString())
   interval := shared.Interval{
   	Quantity: quantity,
   	Unit:     unit,
   }
   intervalSchedule = &shared.IntervalSchedule{
   	Interval: interval,
   }
}

Do you know if this kind of OpenAPI structures are supported by SpeakEasy ?

I can help providing more context if needed (files etc.)

_SPE-1886

oAuth Support (Go)

Servers element should not be required

Just trialling your product with this openapi v3 file: https://raw.githubusercontent.com/amsa-code/egc-api/master/openapi.yml

After requesting Generate in speakeasy self-serve API UI I got this error:

Error: validation error: validate-servers - No servers found in document, either add servers to the document or set a baseServerUrl in the gen.yaml config file
Error: failed to generate SDKs for java 

This api is for use by multiple companies that would implement it separately. The server base url should be configurable at runtime but there should be no need to specify it in the openapi.yml document for your generation to succeed.

[SPE-1864] Add `go mod tidy` before compile step

User could require custom deps which currently fails compile step since go.mod is overwritten by Speakeasy and doesn't contain these deps. Adding go mod tidy before compile step would add these missing deps so the action's compile step can proceed.

_{From SyncLinear.com | SPE-1864}

Allow users to override global retry policy

By default, we have an exponential back-off retry policy however some clients want to be able to control their retry policy. Allowing users to do this would improve our dev. experience.

[SPE-1888] Python sdk occasionally unable to unmarshal list

https://linear.app/speakeasy/issue/SPE-1869/bug-python-sdk-occasionally-unable-to-unmarshal-list

_{From SyncLinear.com | SPE-1888}

[SPE-1904] Granular SDK Versioning

null

_SPE-1904

oAuth Support (Python)

[SPE-1848] Inconsistent tabbing with Terraform usage snippets

_{From SyncLinear.com | SPE-1848}

Status code error handling (Python)

test ticket

Templated server url not adding endpoints correctly upon spec upload

null

_SPE-1853

Status code error handling (Go)

Run Speakeasy Suggest in Github Workflow

null

Credential scanning for SDK files during generation

CRON strings produces inconsistent result after apply in TF providers

_{From SyncLinear.com | SPE-1851}

[SPE-1957] Shorten terraform state property names

Currently our property names are directly tied to our type names. Because we generate a lot of types in the same package, we have long and knarly names to help avoid conflicts.

E.g. In airbyte, the method_standard_inserts inline type is referenced by airbyte_destination_bigquery.bigquery_destination_standard_inserts.loading_method.destination_bigquery_update_loading_method_standard_inserts

This should ideally just be method_standard_inserts.

End-user controlled selection of the response format (Python)

[SPE-1852] [TEMPLATE] USE THIS TO MAKE NEW TICKETS

For Bugs:

Summary: Please provide a short description of the issue you are facing.

• If it is an end user issue (SDK user) any information on the usage interface, i.e. how has the SDK been integrated
• schema used to generate SDK and version of the SDK release

Ticket details

• mark the ticket langauge
• mark the ticket type (Feature, Bug, Documentation)
• Fill in the P level
• leave size and repository empty

_{From SyncLinear.com | SPE-1852}

[SPE-1890] Datasource support for Terraform Provider Generation

_{From SyncLinear.com | SPE-1890}

Spaces in tags causes import errors

Seen in generated python sdks, perhaps others as well.

Current state

When a spec has a tag with a name like Some Tag associated with the paths/endpoints, the generated filename is sometag.py but the import is referenced as from .some_tag import ... which doesn't exist.

Expected output

The import should match the filename.

[SPE-1863] Support async request creation in Typescript SDKs Usage snippets

Update typescript usage snippets to display usage of async/await instead of .then syntax

_{From SyncLinear.com | SPE-1863}

[SPE-2013] Support `const` and `default` attributes [Python]

Allow values to be set without user input

Also single value enums as consts

_{From SyncLinear.com | SPE-2013}

Idempotency header support for retries

Status code error handling (Typescript)

[SPE-1877] Multilevel tagging of resources in SDKs

Enable SDKs to have resource hierarchy that is more than 1 level deep

example: sdk.payments.transfer.get . This could be enabled with the x-speakeasy-group extension in the following manner

x-speakeasy-group:

• "level1.level2"

_{From SyncLinear.com | SPE-1877}

Entire directory cleared on error

Hi,

I am using the CLI installed via homebrew speakeasy version 0.15.7.

I have quickly attempted to generate a Python SDK for a given OpenAPI spec and on error it removes all files in the cwd.

Command: speakeasy generate sdk -s ns_openapi.yml -l python -o .

Tested with yml and json input.

This is using the below example spec with one endpoint and once the above command runs (and fails, but I'll raise another issue for that), the input file has been deleted. I also made a backup in the same cwd and even that was removed on error (ns_openapi.yml, ns_bu.yml):

openapi: 3.0.3
info:
  title: NS Platform Public
  version: 1.0.0
  contact: {}
servers:
  - url: https://platform.neuralspace.ai
  - url: http://localhost
paths:
  /api/ner/v1/project:
    get:
      tags:
        - Named Entity Recognition (NER)
        - Project1
      summary: Get single project
      description: Get single project
      operationId: getSingleProject1
      parameters:
        - name: projectId
          in: query
          schema:
            type: string
            example: 43952a27-be05-4b7b-b4ad-f9df616bbca1
        - name: language
          in: query
          schema:
            type: string
            example: hi
        - name: ''
          in: query
          schema:
            type: string
            example: ''
      responses:
        '200':
          description: ''
    put:
      tags:
        - Named Entity Recognition (NER)
        - Project1
      summary: Update project
      description: Update project
      operationId: updateProject1
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                noOfTrainingJob:
                  type: number
                  example: 3
                projectId:
                  type: string
                  example: 43952a27-be05-4b7b-b4ad-f9df616bbca1
                projectName:
                  type: string
                  example: Hindi Project
            example:
              noOfTrainingJob: 3
              projectId: 43952a27-be05-4b7b-b4ad-f9df616bbca1
              projectName: Hindi Project
      responses:
        '200':
          description: ''
    post:
      tags:
        - Named Entity Recognition (NER)
        - Project1
      summary: Create project
      description: Create project
      operationId: createProject1
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                language:
                  type: array
                  items:
                    type: string
                    example: hi
                  example:
                    - hi
                projectName:
                  type: string
                  example: My first project
            example:
              language:
                - hi
              projectName: My first project
      responses:
        '200':
          description: ''

And the error:

Error: failed to validate schema: invalid paths: invalid path /api/ner/v1/project: invalid operation GET: parameter name can't be blank: invalid path /api/ner/v1/project: invalid operation GET: parameter name can't be blank
failed to validate schema: invalid paths: invalid path /api/ner/v1/project: invalid operation GET: parameter name can't be blank: invalid path /api/ner/v1/project: invalid operation GET: parameter name can't be blank

test

[SPE-2004] Support `const` and `default` attributes [Other languages]

Allow values to be set without user input

_{From SyncLinear.com | SPE-2004}

[SPE-1887] Bug when deserialising json with extra fields

https://linear.app/speakeasy/issue/SPE-1882/java-sdk-gen-bug-when-deserializing-json-with-extra-fields

_{From SyncLinear.com | SPE-1887}

[SPE-2012] Support `const` and `default` attributes [Typescript]

Allow values to be set without user input

Also single value enums as consts

_{From SyncLinear.com | SPE-2012}

End-user controlled selection of the response format (Go)

[SPE-1862] Tutorial for integrating with zod-openapi

null

_SPE-1862

Terraform Import Support

oAuth Support (Typescript)

Local Development Mode for Managed SDKs

For SDKs that fall under the Speakeasy-SDKs organization we will automatically enable local development mode for all customers. This will provide an easy mechanism for developers to locally iterate on their spec and SDK when getting starting with speakeasy.

This entails

• Creating a local version of the source OpenAPI spec in the repo.
• Generating a Makefile that has useful developer commands such as generate SDK and validate spec.
• Pointing the SDK generation workflow to this local spec file.

Please let us know how you like the feature and reach out if you would like this to be extended to repos in your own organization.

Cheers 🥂

[SPE-1889] Handle typenames correctly C#

null

_SPE-1889

Api key not set via managed flow

context

https://linear.app/speakeasy/issue/SPE-1942/repos-can-be-created-without-speakeasy-api-key

[SPE-1875] Bug in handling objects with readonly properties

This is a bug in how we're handling objects with readonly properties. To differentiate the request from the response, we create XInput and X where XInput does not include the readonly properties.

There is an inconsistency in the name of the generated field between regenerations ; we have an un-deterministic suffix for types with readonly: true applied.

The expected behaviour is that the Input type definition is always suffixed with Input, rather than "fighting" over a type name.

_{From SyncLinear.com | SPE-1875}

End-user controlled selection of the response format (Typescript)

Valid input throws

Hi,

I am using the CLI installed via homebrew speakeasy version 0.15.7.

I have a pre-validated OpenAPI spec that throws without an overly useful error message. In the full spec (~200 paths) this appears to be the only issue that speakeasy has. It throws as part of the full spec and in the below reduced spec. The error occurs with both a yml and json input.

Command: speakeasy generate sdk -s ns_openapi.json -l python -o .

Spec:

{
    "openapi": "3.0.3",
    "info": {
      "title": "NS Platform Public",
      "version": "1.0.0",
      "contact": {}
    },
    "servers": [
      {
        "url": "https://platform.neuralspace.ai"
      },
      {
        "url": "http://localhost"
      }
    ],
    "paths": {
      "/api/ner/v1/project": {
        "get": {
          "tags": [
            "Named Entity Recognition (NER)",
            "Project1"
          ],
          "summary": "Get single project",
          "description": "Get single project",
          "operationId": "getSingleProject1",
          "parameters": [
            {
              "name": "projectId",
              "in": "query",
              "schema": {
                "type": "string",
                "example": "43952a27-be05-4b7b-b4ad-f9df616bbca1"
              }
            },
            {
              "name": "language",
              "in": "query",
              "schema": {
                "type": "string",
                "example": "hi"
              }
            },
            {
              "name": "",
              "in": "query",
              "schema": {
                "type": "string",
                "example": ""
              }
            }
          ],
          "responses": {
            "200": {
              "description": ""
            }
          }
        },
        "put": {
          "tags": [
            "Named Entity Recognition (NER)",
            "Project1"
          ],
          "summary": "Update project",
          "description": "Update project",
          "operationId": "updateProject1",
          "requestBody": {
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "properties": {
                    "noOfTrainingJob": {
                      "type": "number",
                      "example": 3
                    },
                    "projectId": {
                      "type": "string",
                      "example": "43952a27-be05-4b7b-b4ad-f9df616bbca1"
                    },
                    "projectName": {
                      "type": "string",
                      "example": "Hindi Project"
                    }
                  }
                },
                "example": {
                  "noOfTrainingJob": 3,
                  "projectId": "43952a27-be05-4b7b-b4ad-f9df616bbca1",
                  "projectName": "Hindi Project"
                }
              }
            }
          },
          "responses": {
            "200": {
              "description": ""
            }
          }
        },
        "post": {
          "tags": [
            "Named Entity Recognition (NER)",
            "Project1"
          ],
          "summary": "Create project",
          "description": "Create project",
          "operationId": "createProject1",
          "requestBody": {
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "properties": {
                    "language": {
                      "type": "array",
                      "items": {
                        "type": "string",
                        "example": "hi"
                      },
                      "example": [
                        "hi"
                      ]
                    },
                    "projectName": {
                      "type": "string",
                      "example": "My first project"
                    }
                  }
                },
                "example": {
                  "language": [
                    "hi"
                  ],
                  "projectName": "My first project"
                }
              }
            }
          },
          "responses": {
            "200": {
              "description": ""
            }
          }
        }
      }
    }
  }

Error:

Error: failed to validate schema: invalid paths: invalid path /api/ner/v1/project: invalid operation GET: parameter name can't be blank: invalid path /api/ner/v1/project: invalid operation GET: parameter name can't be blank
failed to validate schema: invalid paths: invalid path /api/ner/v1/project: invalid operation GET: parameter name can't be blank: invalid path /api/ner/v1/project: invalid operation GET: parameter name can't be blank