band sip: --realm <name> returns 404; only realm ID or FQDN resolves #37

Summary

band sip credential subcommands document --realm as accepting a "Realm ID, name, or FQDN", but passing the realm name returns a 404 from the API. The ID and the FQDN both work. Affects reads and writes alike, so it isn't specific to create.

Version

band version 0.3.0-beta

Reproduction

Given an ACTIVE realm named vapi (band sip realm list shows id: 1163, hostname: vapi-<hex>.auth.bandwidth.com):

$ band sip credential list --realm vapi --plain
Error: API error 404: <?xml version='1.0' encoding='UTF-8' standalone='yes'?><RealmResponse><ResponseStatus><Description>The resource does not exist</Description></ResponseStatus></RealmResponse>

$ band sip credential list --realm 1163 --plain
[]

$ band sip credential list --realm vapi-<hex>.auth.bandwidth.com --plain
[]

Same failure on create:

$ printf '%s' "$PW" | band sip credential create --realm vapi --username vapi-agent --password-stdin --plain
Error: API error 404: ...The resource does not exist...

$ printf '%s' "$PW" | band sip credential create --realm 1163 --username vapi-agent --password-stdin --plain
{
  "hostname": "vapi-<hex>.auth.bandwidth.com",
  "id": "...",
  "realmId": "1163",
  "username": "vapi-agent"
}

Note band sip realm get vapi behaviour is worth checking too — band sip realm get 1163 works.

Expected

Either resolve the name to a realm ID before calling the API (the CLI already has the realm list needed to do this), or drop "name" from the --realm help text so it doesn't advertise an unsupported form.

Why this matters

The help text's own example uses a name:

printf '%s' "$SIP_PASSWORD" | band sip credential create --realm vapi --username vapi-agent --password-stdin

So the documented happy path fails, and the raw XML 404 gives no hint that the fix is "use the ID instead." A name is also the natural thing to reach for in a script, since it's what you passed to band sip realm create --name.

🤖 Generated with Claude Code