Which Sume API routes need no key, and how anonymous calls are limited

Six Sume API routes work without a key: GET /v1/health, GET /v1/catalog, GET /v1/openapi.json, GET /v1/bgm/catalog, GET /v1/bgm/categories and POST /v1/bgm/pick. Everything else under /v1 needs an API key.

Anonymous requests are not unmetered. They are limited per client IP at the Free plan's rate, and their read bucket is held at four times the write rate instead of the forty times that authenticated keys get.

Public routes and what they are for

The list comes from the Sume API reference (read 2026-10-03). The catalog is the one that matters for build-time checks, because the public docs point to it for live pricing metadata.

Check the limits you are actually getting

The rate-limit headers describe whichever budget the current request spent from, and ratelimit-limit is the authority for the deployment you are talking to. Print them for an anonymous call and an authenticated one to see the difference.

curl -s -D - -o /dev/null https://api.sume.com/v1/health | grep -i ratelimit

curl -s -D - -o /dev/null https://api.sume.com/v1/me \
  -H "Authorization: Bearer $SUME_API_KEY" | grep -i ratelimit

Practical consequences

An uptime monitor or a CI step can call health and catalog without storing a secret, but a monitor behind a shared NAT or a build farm shares one client IP, so many callers draw from one anonymous bucket. Give a monitor a real key if it polls often, and keep it on a read-only path.

A 429 names its bucket in error.details.scope as read or write, and the read multiple is a deployment setting, so a preview or self-hosted deployment can differ from the shipped default. Treat the response headers as the source of truth. The per-plan numbers for keys are in the read budget math, and the uptime probe is covered in the health probe post.