Skip to main content
Twilio models a SIP trunk as a container (trunking.v1.trunks) that you decorate with origination URLs, credential lists, and IP access control lists - but the credential lists and IP ACLs actually live in a different API namespace (api.v2010.account.sip.*) and are only associated with the trunk by SID. Vobiz collapses that split: every trunking concept is a first-class, typed SDK resource - trunks, credentials, ip_access_control_list, and origination_uri - all account-scoped by an explicit auth_id. Migration is a resource-for-resource rename plus dropping the cross-namespace association dance.
AUTH_ID is your Vobiz Auth ID (MA_…) and AUTH_TOKEN your Auth Token. In the Vobiz SDK, api_key is the Auth ID (sent as X-Auth-ID) and auth_token is sent as X-Auth-Token. Every trunking method takes auth_id explicitly. Base URL: https://api.vobiz.ai/api/v1.

Twilio → Vobiz mapping

Create a trunk

Termination (outbound) and origination (inbound) both hang off one trunk object. In Vobiz you also set the concurrency cap right here.

Termination auth - credentials and IP allow-lists

This is where the biggest simplification lands. On Twilio you create a credential list in the api.v2010 namespace, add credentials to it, then make a second call to associate the list’s SID with the trunk. Vobiz creates the credential (and the IP rule) as one typed call against the account.
Prefer IP-based authentication for a static SBC? Same story - one call instead of three:

Origination - where inbound calls are delivered

Twilio’s origination URLs carry weight + priority + enabled. Vobiz’s origination_uri carries a priority; add multiple URIs to get ordered failover (the lowest priority number is tried first), which is exactly how you’d replace a disaster_recovery_url.

Route a DID through the trunk

Once the trunk is provisioned, point a purchased number at it so inbound PSTN calls follow your origination URIs.

Key differences

  • Every trunking concept is a typed, top-level SDK resource. trunks, credentials, ip_access_control_list, and origination_uri are first-class clients with full CRUD - no reaching into a separate api.v2010.account.sip.* namespace and then associating SIDs back to the trunk.
  • One call for termination auth. Creating a SIP credential (or an IP rule) is a single create_credential / create_ip_acl call, versus Twilio’s create-list → add-item → associate-with-trunk three-step.
  • Concurrency lives on the trunk. max_concurrent_calls is a plain field on create_trunk/update_trunk, so capacity is explicit per trunk and editable in place.
  • Disaster recovery is just priority. Add lower-priority origination_uri entries and Vobiz walks them in order - the same fallback behaviour as Twilio’s disaster_recovery_url, expressed with the resource you already use for origination.
  • Consistent account scoping. Every method takes auth_id explicitly, so multi-account and sub-account trunk management is uniform across trunks, credentials, origination_uri, and number assignment.
  • Auth is header-based. Set X-Auth-ID + X-Auth-Token once on the client instead of HTTP Basic on each request; the same client also drives voice, numbers, and CDRs.
  • Trunk-call visibility via CDRs. client.cdr.list_cdrs(auth_id, sip_call_id=…) lets you query completed trunk calls - including by SIP Call-ID - from the same SDK.
Migrating call-control flows too? <Gather> covers your IVR menus. See the full Twilio → Vobiz overview for the migration order across trunking, numbers, and voice.