One Sume API key per service: what it isolates and what it does not

Teams often split one Sume API key into one per service on the theory that a busy poller will starve the submitter. The rate limit docs say each key gets its own per-minute budget, set by the workspace plan, and that reads and writes have separate budgets, so a tight status-poll loop cannot cause a 429 on your own submits. Separate keys are still worth having, for different reasons.

Generation capacity is a different limit. The plan's concurrency and queue size do not grow when you add keys, so a second key does not buy more parallel images.

What a separate key does

Check each key in one loop

Each response carries ratelimit-limit and ratelimit-remaining, so one GET /v1/me per key shows its budget. The loop reads each key from an environment variable, never from the command line.

for name in SUME_KEY_SUBMITTER SUME_KEY_POLLER SUME_KEY_WEBHOOKS; do
  echo "== $name"
  curl -sS -o /dev/null -D - https://api.sume.com/v1/me \
    -H "x-api-key: ${!name}" | grep -iE '^(HTTP|ratelimit-limit|ratelimit-remaining)'
done

Suggested split

• A submitter key for your worker that creates jobs and runs.
• A poller or reconciler key, with only the access it needs.
• A webhook-admin key used for secret reads and rotation, since those need account:read and account:write.
• A monitor key for uptime probes, so alert traffic never shares a budget with production.

Rotation stays simple

Per-service keys make rotation small: create the replacement, verify it with GET /v1/me, deploy it to that service, then revoke the old key. Keys stay on servers; do not put any of them in browser or mobile code.