Skip to main content
Komga SDK 1.0 exports generated operation functions and generated API types alongside client helpers. Use ESM imports and strict TypeScript settings so flat parameters, optional page fields, and result branches are checked at compile time.
The SDK package is ESM. Use import type for types that are erased at runtime and a current TypeScript-aware Node, Bun, or bundler runtime. The SDK core uses platform Fetch; use Node.js 18+, a modern browser, or provide a compatible fetch implementation through createKomgaClient.

Import generated types

The package root re-exports generated DTOs, search types, page types, operation response types, and operation error types:
Generated page fields such as content, totalElements, and totalPages may be optional. Narrow or provide defaults before using them. Do not add fields from old service-layer search models when they are not present in the generated type.

Type flat operation parameters

Generated signatures catch wrong parameter names and prevent the removed grouped call shape:
Use the generated DTO property name for body parameters, such as bookMetadataUpdateDto in updateBookMetadata. Use the generated query name, including names such as library_id, exactly as exported.

Infer an operation’s result

An operation’s default return type is a Promise of its generated result contract:
The operation options parameter is optional in the generated signature; Parameters<typeof getBookById>[1] therefore includes undefined. In application code, pass { client } as the second argument when using an isolated client. Prefer Awaited<ReturnType<...>> over manually recreating { data, error, request, response } unions.

Public helper types

The package root also exports:
  • KomgaClientOptions and AuthConfig for createKomgaClient.
  • KomgaResult for the default { data, error, request, response } result shape.
  • KomgaApiError and unwrap for an explicit throwing boundary.
  • Client and GeneratedClientConfig for advanced generated-client integrations.
  • Generated DTO, page, search, operation response, and operation error types.
Generated types describe the API contract to TypeScript. They do not validate data at runtime, make optional fields required, or add runtime error classes. Add an application-owned validator at the boundary if your integration needs runtime checks.

Narrow result branches

Use error === undefined as the discriminant before reading data:
request and response are optional because network or request-construction failures can happen before Fetch returns a response. Successful void operations have data: undefined; binary operations use their generated media type and may require a parseAs option.

Avoid unsafe assertions

Do not cast a result to a DTO before checking its error branch, and do not use any to bypass generated parameter errors:
If a server response is untrusted, narrow it with an application-owned schema rather than asserting that it is a generated type. See Runtime validation.

Next steps