Explicit key vs saved login: auth order in the Sume CLI

Sume's docs do not state a precedence order between a saved sume login key and SUME_API_KEY, so do not rely on one. What they do state is that the CLI defaults to x-api-key, and that any request carrying both Authorization: Bearer and x-api-key fails with 401 unauthorized.

Why precedence matters

A saved login and an environment key can both exist on one machine, for example a laptop that runs sume login and also exports SUME_API_KEY for a script. If you cannot tell which one a command used, spend and audit trails are harder to read. Set one explicitly in each environment.

What the Sume docs say

sume login opens a device approval page, waits, and stores a CLI-scoped API key in ~/.sume-com/config.json by default. SUME_API_KEY is documented for CI and server automation, SUME_API_AUTH_MODE is x-api-key or bearer, and SUME_CONFIG_DIR overrides the config directory.

sume auth status shows login state and sume doctor --agent --json inspects local readiness without calling the API. Never print or commit SUME_API_KEY or the config file.

A setup that does not depend on precedence

Make one credential the only one in each environment.

• Laptop: run sume login and leave SUME_API_KEY unset.
• CI: set SUME_API_KEY from a secret manager, and point SUME_CONFIG_DIR at an empty temporary directory so no stale login can be read.
• Run sume auth status at the start of a job and fail fast if it is not what you expect.
• Do not add an Authorization header to the same requests; send exactly one credential.

The two-header trap

The API docs say neither header wins when both are present, and the second does not shadow the first. The result is a 401 with the message Send only one API key credential. The usual cause is a gateway or fetch wrapper that adds its own Authorization header. Strip one rather than hunting for a precedence rule that does not exist.