fix: make machine account credentials files portable across environments

[scotwells]

Summary

Machine account credentials files no longer need to carry environment-specific configuration. datumctl now discovers the auth endpoint from --hostname — the same way interactive login already works — so the same credentials file can be used against dev, staging, and production by simply pointing datumctl at a different hostname.

What changed for users

Before this fix, a credentials file had to contain api_endpoint, token_uri, scope, and project_id or login would fail with:

error: credentials file is missing required fields: [token_uri client_email ...]

After this fix, a minimal credentials file only needs:

• type (must be datum_machine_account)
• client_id
• private_key_id
• private_key

client_email is optional and only used for display. Older credentials files that still include the extra fields continue to work unchanged.

One thing to know when migrating

If you were previously logging in against a non-default environment using just --credentials old-file.json (and relying on the file's token_uri to pick the environment), you will now need to pass --hostname explicitly:

datumctl auth login --credentials ./my-key.json --hostname auth.staging.env.datum.net

The login examples in datumctl auth login --help have been updated to show this.

Fixes #144

Test plan

• Log in with a minimal credentials file (only type, client_id, private_key_id, private_key) against the default hostname
• Log in with a minimal credentials file plus an explicit --hostname pointing at a non-default environment
• Log in with a legacy credentials file that still has all the old fields and confirm it still works
• Confirm an authenticated session can refresh its token after the initial login without re-reading the credentials file
• Confirm a missing required field (e.g. no `private_key`) still produces a clear error

🤖 Generated with Claude Code