band sip status reports "available" on accounts where realm creation fails #36

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 SipCredentialSettings

On 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