Sume SDK function name for an endpoint: the camelCase operationId

In @sume-com/sdk the function for an endpoint is named after the endpoint's OpenAPI operationId, written in camelCase. So GET /v1/catalog is not getCatalog; it is listPublicApiCapabilities, because that is its operation id in the schema. If a method you expect is missing from autocomplete, search the OpenAPI by path and read the id, not the URL.

The TypeScript SDK page says it directly: a generator makes every export other than the hand-written helpers from the same schema, there is one function per operation, and the function name is the operation id. This post shows how to turn a path into a name in about a minute.

Where the name comes from

The schema at apps/docs/public/api/openapi.json holds 183 operations as of the 2026-10-10 read, each with an operationId. The docs site publishes the same schema, and the API reference is rendered from it. The SDK generator turns each id into one exported function.

Most ids are already camelCase, so the function name is identical. A group of ids is written in snake_case in the schema, such as the Firecrawl and ScrapeCreators routes. For those the generated function is the camelCase form, so firecrawl_scrape becomes firecrawlScrape.

Path to function name, read 2026-10-10

The first row is the one that trips people up. The route is called catalog, but the operation is named for what it returns, the public API capabilities. The video routes are the second surprise: they are createVideoGeneration and getVideoGeneration, not generateVideo.

Find the id for any route

Do not guess from the URL. Look the route up in the schema, and use the string you find. A short script over the JSON does it, and the same file is what the docs site publishes.

The pattern works for every route, including the ones in the table above. Once you have the id, convert any underscores to camelCase and import that name from the package.

• Open apps/docs/public/api/openapi.json, or the schema served from the reference page.
• Find the path and method, and read the operationId on it.
• If the id contains underscores, camelCase it: firecrawl_crawl_get is firecrawlCrawlGet.
• Import the name from @sume-com/sdk and pass the client you created.

Call it, and read the result

Create the client once, and pass it on every call. The default client in the package has no key and exists only so the generated code compiles. The client sends x-api-key only, so do not add an Authorization header yourself, because the API refuses a request that carries both.

Generated functions do not throw on an API error. They resolve with { data, error, response }, so check error before you use data. The hand-written polling helpers behave differently and do throw, which is a reason to keep the two styles apart in your own wrappers.

import { createSumeClient, listPublicApiCapabilities } from "@sume-com/sdk";

const client = createSumeClient({ apiKey: process.env.SUME_API_KEY! });

// GET /v1/catalog -> operationId listPublicApiCapabilities
const { data, error, response } = await listPublicApiCapabilities({ client });
if (error) {
  console.error(response.status, error);
} else {
  console.log(data);
}

What the names do not tell you

A function name says nothing about cost or scope. A video route spends credits, and a key needs the right scopes for its routes, which are fixed at creation. Read the authentication docs before you pick a key for a script.

For a long job, use the helpers rather than hand-rolling a loop. The same SDK page lists waitForRun, waitForJob and subscribeFormatRun. Keep the generated names in one thin module in your codebase, so a renamed operation id shows up as a single compile error rather than a scatter of runtime failures after an upgrade. Pin the package version as well, since the names follow the schema. See also job id or run id: which endpoint and helper to poll.