Sume API catalog: list available models, endpoints, and prices

To list the models and capabilities available on the Sume API, call GET /v1/catalog. It needs no API key and returns one entry per capability with its Sume model ids, endpoint paths, availability, runtime readiness, and pricing metadata, which makes it the docs' recommended starting point for programmatic discovery.

The fields below come from Sume's Core concepts and API reference docs and the catalog schema in the live Sume API reference, read on 2026-09-26.

How do I call the catalog?

Send a plain GET. Every /v1 endpoint needs an API key except a short list of public routes, and GET /v1/catalog is on it with GET /v1/health and GET /v1/openapi.json. Send your key when you want the prices your own workspace pays, as described below. In the TypeScript SDK, the generated function is listPublicApiCapabilities.

curl -s https://api.sume.com/v1/catalog \
  | jq '.data[] | {id, api_type, invoke_url, availability, beta}'

What does each catalog entry contain?

The response carries apiVersion, status, and a data array with one entry per capability. These are the fields to build on:

How do I check that a model is available before I call it?

Read availability, not status. The schema keeps status as a backward-compatible, human-readable readiness string and points machine decisions to availability, runtime, and billing. beta: true marks a capability whose contract is available before the full provider workflow is generally available.

• After a 404 model_not_found, the admission docs say to use /v1/catalog or verify ids.
• Before retrying a 503 provider_not_configured, check catalog and runtime status instead of retrying aggressively.
• Internal voice capabilities, raw provider model ids, and provider task URLs are not public API unless they appear in /v1/catalog and the OpenAPI schema.

How does the catalog show prices?

Paid capabilities carry a pricing block in USD with billing_unit: usd_cent, billable_amount: sume_price, and a reservation_policy. Each model_pricing[] entry adds estimated_usd_cents, minimum_usd_cents, maximum_usd_cents, and a pricing_basis, and can carry title, price, and unit strings. These are rounded estimates: submit-time reservations store exact USD micros and expose rounded-up cents.

The applied_*_usd_cents fields are the estimate an authenticated workspace actually pays under its price book, split into a model line (applied_model_estimated_usd_cents) and an Agent Fee line (applied_agent_fee_estimated_usd_cents). price_book names the terms behind them as discount_bps and agent_fee_bps. Usage is billed at published rates plus a 5.5% agent fee by default.

The API pricing rate card points back here: full rates for managed models and routers are in GET /v1/catalog.

Is the catalog the same as GET /v1/videos/models?

No. GET /v1/videos/models lists only video generation models, each with its supported resolutions, durations, and pricing SKUs; An OpenRouter-compatible video API covers it. The catalog covers more than video: its model ids run from sume/avatar-1.0/generate and sume/music-router to media tools such as sume/timeline-1.0 and sume/video-trim-1.0.

What does the catalog not tell you?

It is a map of capabilities, not the whole contract:

• Request fields. Exact request and response schemas come from the live OpenAPI at https://api.sume.com/reference/json.
• Formats. GET /v1/formats lists the Formats visible to your key: your own plus the first-party catalog.
• Your bill. Catalog cents are estimates; GET /v1/usage and GET /v1/balance are the billing records.