A carrier account is the credential Talqing uses to reach a phone network on your behalf. Every phone number hangs off one. You connect the account you already have with that carrier — Talqing never resells you phone service, and the carrier’s invoice stays yours. Four carriers are supported. Nothing else can be connected. GET /v1/telephony/providers returns the same list at runtime, with the exact field keys, labels, defaults and hints the dashboard renders. Read it rather than guessing field names.

​
Connecting an account

Two calls. The first records the credential and checks it against the carrier; the second builds the carrier-side setup.
display_name is yours and must be unique in the workspace. Connecting a second account with the same carrier identity — the same Plivo Auth ID, the same Twilio or Exotel Account SID — is a 409.

​
Credentials become workspace secrets

Send a credential as plaintext and Talqing stores it as a workspace secret named after the carrier and the field — PLIVO_AUTH_TOKEN, EXOTEL_API_TOKEN — and keeps only the reference. If that name is already taken by something else, a suffixed name is allocated rather than overwriting it. You can also pass a secret you created yourself:
The API never echoes a resolved credential. GET on an account returns the {{secrets.NAME}} reference map and nothing else. Creating an account validates the credential against the carrier immediately. A credential the carrier rejects leaves the account in error with the carrier’s own message on status_message — the account is still there, so you can fix it with a PATCH rather than starting again. A PATCH to credentials merges, so you can rotate one key without re-sending the others. Run provision again afterwards.

​
What provisioning builds

POST /v1/telephony/accounts/{account_id}/provision creates the carrier-side objects that let calls flow in both directions, and the outbound identity Talqing dials with. Run it after connecting an account, and again after replacing its credentials. It is safe to repeat. It converges the carrier side to what the account should have rather than creating a second copy of anything. The response’s status and setup_steps say what is working and what is left.

​
Account statuses

PATCH accepts only disabled and connected on status. The other four are states the platform writes.
Disabling an account tears down inbound routing for every number on it, immediately, before the row flips — so calls cannot keep arriving at a carrier the dashboard already shows as off. Re-enabling the account does not put that routing back on its own: each number needs POST /v1/telephony/phone-numbers/{number_id}/provision again.

​
Setup steps you do in the carrier’s console

Some carrier work happens in the carrier’s own product, and no API can read it back. That is what an account’s setup_steps are for: each step carries a title, a detail, numbered instructions, a link to the carrier’s own documentation, and done. A step marked user_confirmable: true cannot be checked over any API. You do it, then you tell Talqing you have done it:
While a user_confirmable step is outstanding, inbound calling on that account’s numbers does not work, whatever else the dashboard says. Read setup_complete and setup_steps rather than inferring readiness from status. Outbound calling is unaffected.
Confirming flips can_inbound to true on every non-disabled number on the account. Setting it back to false reverses that just as broadly.

​
Per-carrier setup

Account info: auth_id — from the Plivo console home page, in the form MAXXXXXXXX.Credentials: auth_token — the auth token shown beside it.Everything else is driven over Plivo’s API. Provisioning leaves nothing for you to do in the Plivo console, and the account has no setup steps.
Account info: account_sid — from the Twilio console home page, in the form ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.Credentials: auth_token — the auth token shown beside it.Twilio’s API host is the same worldwide, so there is no region or subdomain to copy across. Provisioning leaves nothing for you to do in the Twilio console, and the account has no setup steps.
Account info: auth_id — from the Vobiz console home page, in the form MA_XXXXXXXX.Credentials: auth_token — the auth token shown beside it.Vobiz serves every account from one global API host, so there is no region or subdomain to copy across. Provisioning leaves nothing for you to do in the Vobiz console, and the account has no setup steps.
Account infoCredentials: api_key and api_token, both from Exotel’s API Settings page.The console step. Exotel can only hand an incoming call to a Flow, never straight to a connection. So your numbers need a small Flow that passes the call to Talqing. It takes about two minutes, once per account — not once per number.
1

Create a Custom App

In Exotel’s App Bazaar, under Custom Apps, click Create. Name it something like “Talqing inbound”.
2

Add the Connect applet

Drag the Connect applet from Voice Applets onto Call Start. Leave “Configure using flow builder here” selected, and leave both Primary URL boxes empty — those are for calling a webhook of your own, not for reaching Talqing.
3

Point it at Talqing

Under Dial Whom, pick Dial phone number(s) and paste the value the setup step gives you — it begins sip: — into that box, then save the Flow. The box asks for a phone number; the sip: prefix is what overrides that and tells Exotel to hand the call over instead of dialling anyone. Read the value from setup_steps on the account (the dashboard renders it with a Copy button); it is specific to your account.
4

Attach your numbers to the Flow

In ExoPhones, click Assign ExoPhones to Flow, tick every number Talqing should answer and the Flow you just made, then click Attach Flow. A number still showing “Install an App” is not connected yet.
5

Confirm it here

PATCH /v1/telephony/accounts/{account_id} with {"console_setup_confirmed": true}, or press the confirm button in the dashboard.
Until you confirm, every Exotel number imports with inbound disabled — its readiness reads needs_carrier_setup and it cannot be assigned an agent. Outbound calling from those numbers works the whole time.

​
Disconnecting an account

DELETE /v1/telephony/accounts/{account_id} is permanent, and it is guarded on both sides.
  • Every number on the account must be disabled first. A number that is pending, provisioning, active or error blocks the delete with disable all phone numbers on this account before deleting it. This is what stops a delete quietly taking live numbers off the air.
  • The carrier-side teardown has to succeed. Talqing removes the objects it created on your carrier account before dropping the row that records their ids. If the carrier refuses — an expired credential, an API outage — the delete fails with a 502 naming the carrier’s reason, and nothing is removed here. Fix the credential and retry.
Only objects Talqing created are touched. Nothing you built yourself in the carrier’s console is deleted, and your numbers stay yours.

​
Next

Phone numbers

Import the numbers this account owns and put an agent on one.

Troubleshooting

Credential expiry, setup that will not finish, numbers stuck in error.