Migrate Twilio subaccounts to Vobiz. Map api.accounts.create / list / update(status) and subaccount auth to Vobiz sub_accounts.create_subaccount / list / retrieve / update / delete, plus built-in customer KYC (PAN, GST, CIN, DigiLocker, hosted sessions) for your customers.
Twilio’s Account resource lets you spin up subaccounts under one parent for multi-tenant isolation and per-tenant billing. Vobiz gives you the same model with the sub_accounts resource — plus a first-class customer KYC pipeline (PAN, GST, CIN, DigiLocker, hosted verification sessions) so each customer sub-account can be onboarded and compliant before it ever places a call.If you already have a Twilio integration, this is mostly a rename-and-add-auth_id job. Every account-scoped Vobiz method takes your master auth_id explicitly, and the sub-account is addressed by its own sub_auth_id.
Set credentials once: AUTH_ID is your Vobiz master Auth ID (MA_…) and AUTH_TOKEN is its Auth Token. In the Vobiz SDK api_keyis the Auth ID (sent as X-Auth-ID), and auth_token maps to X-Auth-Token. Base URL: https://api.vobiz.ai/api/v1.
Twilio’s accounts.create becomes sub_accounts.create_subaccount — add your master auth_id and use name instead of friendly_name. Both return the new tenant’s own credentials.
Where Twilio hands you a bare subaccount, Vobiz lets you gate the tenant behind verification. Create it with kyc_mode="customer_use" (this requires an email) and pass the customer’s business_type to drive which documents are needed. A fresh customer_use sub-account starts with kyc_calls_blocked: true, then flips live once KYC passes — no external compliance stack to build.
# 1) Create a KYC-gated customer sub-accountsub = client.sub_accounts.create_subaccount( auth_id=AUTH_ID, name="Customer Co", email="ops@customer.co", kyc_mode="customer_use", business_type="private_limited",)SA_ID = sub.auth_id # e.g. "SA_…"# 2a) Verify documents directly through the APIclient.sub_account_kyc.verify_subaccount_pan(sub_auth_id=SA_ID, pan="ABCDE1234F")client.sub_account_kyc.verify_subaccount_gst(sub_auth_id=SA_ID, gstin="29AAJCN5983D1Z0")# 2b) …or let the customer self-serve via a Vobiz-hosted sessionsession = client.sub_account_kyc.create_subaccount_kyc_session( sub_auth_id=SA_ID, account_auth_id=SA_ID, flow_type="email", # emails a signed link from kyc@vobiz.ai customer_email="ops@customer.co", webhook_url="https://your-app.example.com/kyc/webhook", expires_in_days=30,)# 3) Check aggregated KYC state before enabling callsstatus = client.sub_account_kyc.get_subaccount_kyc_status(sub_auth_id=SA_ID)
For a company, run search_subaccount_cin(company_name=…) to get candidate matches, then confirm_subaccount_cin(selected_cin=…). For an individual, use subaccount_digilocker_initiate(redirect_url=…) and finish with subaccount_digilocker_verify(...) after the customer completes the DigiLocker OAuth flow.
Twilio drives lifecycle through the status enum (active / suspended / closed). Vobiz splits this into a reversible enabled toggle and an explicit delete, so “pause” and “permanently remove” are separate, deliberate calls.
On Twilio you re-authenticate with the subaccount’s own SID and Auth Token to make calls “as” that tenant. Vobiz works the same way: each sub-account has its own Auth ID and Auth Token, and you pass those as the auth_id on account-scoped methods (make_call, phone_numbers.*, cdr.*, and the rest). Calls, numbers, recordings and CDRs are all scoped to whichever Auth ID you present, so billing and data stay cleanly isolated per tenant and roll up to the master.
# Instantiate against the sub-account's own credentials …tenant = Vobiz(api_key=SUB_AUTH_ID, auth_token=SUB_AUTH_TOKEN)tenant.calls.make_call( auth_id=SUB_AUTH_ID, from_="+14155551234", to="+14165553434", answer_url="https://example.com/answer.xml", answer_method="POST",)# … or assign a purchased number to the tenant from the master accountclient.phone_numbers.assign_did_to_subaccount( AUTH_ID, e164="+14155551234", sub_account_id="SA_XXXX",)
Explicit auth_id everywhere. Twilio infers the account from the credentials on the client; Vobiz passes the Auth ID on each account-scoped call. This makes master-vs-tenant context obvious in code and easy to audit.
Reversible pause is its own field. Twilio overloads one status enum; Vobiz uses enabled (True/False) for pause/resume and a separate delete_subaccount for permanent removal — so a routine “pause billing” can never be confused with an irreversible close.
Customer KYC is built in. Twilio gives you the tenant container; Vobiz adds sub_account_kyc.* on top — PAN, GSTIN, CIN, and Aadhaar-via-DigiLocker verification, plus Vobiz-hosted email/redirect sessions from kyc.vobiz.ai. You can onboard regulated Indian customers without building a compliance stack.
KYC-gated go-live. With kyc_mode="customer_use", a new tenant starts with kyc_calls_blocked: true and flips live automatically once verification passes — a clean, provable onboarding gate. personal_use sub-accounts simply inherit the master’s KYC.
Number assignment is a first-class call. Move a purchased DID to a tenant with phone_numbers.assign_did_to_subaccount(...), keeping ownership and billing under the master while the tenant uses the number.
Self-service onboarding.create_subaccount_kyc_session(...) hands the whole verification flow to your customer via a signed email link or an inline redirect widget, with results delivered to your webhook_url.
