Generated-code conventions

Hey API generates the SDK from:

packages/core/openapi.yml

The generation configuration is:

packages/core/openapi-ts.config.ts

Regenerate the SDK

From packages/core:

bun run openapi-ts

The generator writes into packages/core/src/ and runs deno fmt as a post-process step.

Do not edit generated files

Files ending in .gen.ts begin with an auto-generated notice. Change the OpenAPI document or generator configuration, then regenerate instead of editing output by hand.

Generated output includes:

• sdk.gen.ts for service classes and methods.
• types.gen.ts for schemas and operation data.
• client.gen.ts and client/ for the Fetch client.
• core/ for request serialization and authentication helpers.
• index.ts for public exports.

Naming and grouping

The SDK plugin uses:

operations: {
  strategy: 'single',
  containerName: {
    name: 'DSPlaneCore',
    casing: 'preserve',
  },
  methods: 'instance',
}

The generated root class is therefore exactly DSPlaneCore.

Operation nesting applies these rules:

OpenAPI path	Generated service
/ws-manager/*	DSPlaneCore.wsManager
/key	DSPlaneCore.wsManager
/llm/*	DSPlaneCore.deployments

Method signatures

paramsStructure: "flat" groups operation parameters in one object:

await dsplane.wsManager.fetchEnvironment({
  wsID: 'workspace-id',
});

responseStyle: "data" returns the response body shape rather than requiring callers to unwrap a response object.

Imports

Use the package exports rather than generated file paths:

import { DSPlaneCore, type EnvironmentConfig } from '@dsplane/core';
import { createClient } from '@dsplane/core/client';

Avoid imports such as @dsplane/core/src/sdk.gen.ts. They bypass the public package boundary and couple your code to generated layout details.