Summary
band sip status returns available / probe_succeeded on accounts that are not enabled for SIP credentials, where band sip realm create immediately fails. The probe is the documented way to answer "can this account use SIP provisioning?", so a false positive sends you down a dead end.
Version
band version 0.3.0-beta
Reproduction
On an account without SipCredentialSettings enabled:
$ band sip status --plain
{
"reason": "probe_succeeded",
"status": "available"
}
$ band sip realm list --plain
[]
$ band sip realm create --name vapi --default=false --wait --plain
Error: this account isn't enabled for SIP credentials — contact Bandwidth support to enable SipCredentialSettingsOn a different account that is enabled, band sip status returns the identical response, and realm create succeeds. So the probe returns the same available / probe_succeeded in both cases and cannot distinguish them.
Expected
band sip status should report unavailable when account-level SIP credential configuration is missing, ideally with the same actionable reason the create path already produces — something like:
{
"status": "unavailable",
"reason": "sip_credential_settings_disabled"
}Why this matters
The command's own help text makes this its whole job:
Probes the SIP API to resolve the 'unknown' capability reported by 'band auth status'. SIP provisioning requires both the SIP Credentials role and account-level configuration; only the probe can confirm the latter.
Account-level configuration is exactly what it fails to confirm. This is also the kind of preflight an agent or script gates on — a false green light means wiring up half an integration (in my case, a third-party SIP trunk on the far end) before discovering the account was never eligible.
Suspected cause
The probe looks like it only exercises a read path (realm list succeeds and returns [] on the disabled account). A successful list doesn't imply write eligibility. Checking the capability the create path checks — or attempting a dry-run/no-op write — would close the gap.
🤖 Generated with Claude Code
Summary
band sip statusreturnsavailable/probe_succeededon accounts that are not enabled for SIP credentials, whereband sip realm createimmediately fails. The probe is the documented way to answer "can this account use SIP provisioning?", so a false positive sends you down a dead end.Version
band version 0.3.0-betaReproduction
On an account without
SipCredentialSettingsenabled:On a different account that is enabled,
band sip statusreturns the identical response, andrealm createsucceeds. So the probe returns the sameavailable/probe_succeededin both cases and cannot distinguish them.Expected
band sip statusshould report unavailable when account-level SIP credential configuration is missing, ideally with the same actionable reason the create path already produces — something like:{ "status": "unavailable", "reason": "sip_credential_settings_disabled" }Why this matters
The command's own help text makes this its whole job:
Account-level configuration is exactly what it fails to confirm. This is also the kind of preflight an agent or script gates on — a false green light means wiring up half an integration (in my case, a third-party SIP trunk on the far end) before discovering the account was never eligible.
Suspected cause
The probe looks like it only exercises a read path (
realm listsucceeds and returns[]on the disabled account). A successful list doesn't imply write eligibility. Checking the capability the create path checks — or attempting a dry-run/no-op write — would close the gap.🤖 Generated with Claude Code