sip_trunk.provisioning_failed

Summary

sip_trunk.provisioning_failed is returned from the Sautikit operations approval action for a signaling (ip_allowlist) trunk — it is not something your own API calls can trigger directly. You may still see its effects: a trunk you submitted for review stays at pending_approval, or moves to failed, longer than expected.

Cause

Signaling-mode trunks require a person at Sautikit to review and approve them, because allowlisting a customer's IP is a platform-wide trust grant on the PBX — the box's carrier-facing profiles run with no per-call authentication, so that allowlist is the only gate on who can send it a call. Approval installs both your signalling IPs (call setup) and your media IPs (audio) into that allowlist, then activates the trunk. This error means one of those steps failed:

• Adding one of your signalling or media IPs to the box's allowlist was rejected or timed out.
• The allowlist install succeeded but the trunk failed to flip to active, or the record of who approved it failed to write — in which case the trunk is often already active on the box even though the approval call itself errored.

Resolution

This is not a state a customer request can retry — it happens on Sautikit's side during review. If your trunk has been at pending_approval for longer than expected, or shows failed with a last_error mentioning the allowlist:

curl "https://api.sautikit.com/v1/sip-trunk" \
  -H "Authorization: Bearer $SAUTIKIT_API_KEY"

check last_error for detail, and contact support with your workspace ID. Re-approval is idempotent on Sautikit's side — a retried approval does not duplicate allowlist entries.

Example response

{
  "error": {
    "code": "sip_trunk.provisioning_failed",
    "message": "add allowed source 203.0.113.10/32: dial tcp: i/o timeout",
    "request_id": "req_01900000abc"
  }
}

Next steps

• Numbers concepts — bring your own SIP trunk
• sip_trunk.not_found — check whether a trunk exists at all