Skip to main content
Komga keeps older HTTP routes for compatibility, but new integrations should use the current generated operations. The replacement functions below are exported by komga-sdk 1.0 and use flat parameters.
Do not add new code against the legacy routes. Their response shapes and availability can change as Komga removes compatibility endpoints.

Replacement map

No deprecated SDK function imports are needed. Import the current operation instead. The migration is more than a path change: The generated functions serialize the nested search/update value for you. Do not pass a legacy { path, query, body } object or put pagination inside the search document. For the list operations, bookSearch and seriesSearch are required even when the search is empty ({}).

Replace the books list call

getBooks takes pagination at the top level and the search document as bookSearch:

Replace the series list call

getSeries uses the same flat pagination shape with a seriesSearch document:
Alphabetical groups require only the flat seriesSearch parameter:

Replace the authors list call

getAuthors is the current v2 operation. Its filters are flat query keys: The v2 operation preserves the useful filters that callers often encoded in the old route, but makes their types explicit. For example, library_id accepts an array and the current operation also supports role, readlist_id, unpaged, and size:
Treat an empty content page as a valid “no matches” result. A 400 usually means a filter or pagination value is invalid; inspect result.error and the native response before retrying.

Replace a library update

The current operation uses PATCH and names the body parameter libraryUpdateDto:

Migration checklist

  1. Replace each legacy route with the current operation in the table.
  2. Move path, query, and body values into the operation’s flat parameter object.
  3. Pass { client } as the second argument when the operation has parameters.
  4. Check result.error or call unwrap for a typed KomgaApiError.
  5. Treat 204 responses as successful operations with no data payload.

Next steps

Direct API

Explore generated operations and response fields.

Library maintenance

Scan and update libraries with current operations.

Migration

Review SDK 1.0 migration changes.