Telephony
Connect a number or your own SIP trunk
Two ways to put an agent on the phone. Connect your provider's SIP trunk yourself on Numbers & SIP, and your agents answer your own numbers and call out through it. Or ask WeTalk for a number, and an operator connects it to your agent.
Paths, field names, enum values, headers and error codes in these samples are the real ones, checked against the API's own specification when this page is built. The ids, amounts and names in them are illustrative. `$WETALK_API_KEY` and `$AGENT` are shell variables you set yourself.
Connect your own SIP trunk
If your numbers are with a VoIP provider or on your own phone system, connect it yourself: open Numbers & SIP in the console and choose “Connect a trunk”. No carrier from WeTalk is needed. Your provider's portal has what to enter, usually on a page called SIP trunk, SIP account or connection settings.
Your provider bills its own minutes for calls through your trunk; WeTalk bills talk time as usual. Audio passes through WeTalk's servers in Italy North.
- Host and port — your provider's SIP server, like sip.provider.com, and its port (usually 5060, or 5061 for TLS).
- Transport — UDP, TCP or TLS, as your provider says.
- Username and password — what WeTalk signs in to your provider with. The password is kept in WeTalk's vault and never shown again, here or anywhere; replace it any time.
- Your numbers (the DIDs your provider gave you), in international form with +, and which of them are caller-ID numbers your agents may call out from.
- How your provider writes numbers (with +, without +, with 00, or national) and how caller ID is presented. The dialog writes your first number out each way.
- The countries the trunk may ring. At launch that is Greece only. Emergency, short and premium-rate numbers are never rung.
Check the connection, then place a test call
A new trunk reads “Not verified yet”. “Check connection” on its card asks your provider's SIP server to answer, from WeTalk's own address, and says what happened in plain words: whether the host was found, whether a SIP server answered, whether your username and password were accepted, and whether a TLS certificate could be verified. The check is free and rings nobody. A trunk can be checked again after a short wait, and an account has a daily number of checks; a refusal says how long to wait.
If your provider allow-lists addresses, add WeTalk's SIP address, shown on Numbers & SIP under “Where to point your provider”, for signalling and audio. If your provider does not answer unknown addresses at all, place a test call instead: “The agent calls me” rings your phone from one of the trunk's caller-ID numbers, and “I call the agent” waits two minutes for you to ring one of its numbers. A test call is billed talk time like any other.
The trunk reads “Verified” once a check finds it reachable with your username and password accepted (or with no sign-in asked for), or once a test call through it connects.
curl https://api.wetalk.io/v1/sip-trunks \
-H "Authorization: Bearer $WETALK_API_KEY"
curl https://api.wetalk.io/v1/sip-trunk-settings \
-H "Authorization: Bearer $WETALK_API_KEY" curl https://api.wetalk.io/v1/sip-trunks/$TRUNK/check \
-X POST \
-H "Authorization: Bearer $WETALK_API_KEY" Receiving conversations through your trunk
To let your provider send calls to WeTalk, add its signalling addresses to the trunk (Edit → Allowed addresses) and choose “Create sign-in details” under Receive. WeTalk generates a username and password for your provider to present and shows the password once. Paste both into your provider's settings for calls it sends to WeTalk (often called the destination), with WeTalk's SIP host as the address. WeTalk accepts a call only when it comes from an allowed address and signs in with those details; creating them again replaces both.
Then connect a number to an agent: on the agent's Channels tab, under “Connect a trunk number”, pick one of the trunk's numbers and choose Connect, or pick the agent beside the number on the trunk card. Connecting it to another agent replaces the first.
Until everything is in place, the trunk card says what is still missing: receiving through your own trunk switched on at WeTalk, the trunk enabled and verified, your provider's addresses, WeTalk's sign-in details, and a number connected to an agent.
Calling out through your trunk
Outbound conversations go through your own SIP trunk, from one of its caller-ID numbers connected to the agent, and the trunk must be verified and enabled. On the agent's Outbound tab, “New campaign” asks which number the campaign calls from, and “Ring a number now” rings one number straight away: the number to ring, the number to call from, how long to ring (30 seconds unless you change it, at most 80) and an optional reference that is shown in History and never told to the person you ring. It is billed talk time from when they answer. Closing the window does not hang up — use End.
At launch WeTalk rings Greek numbers only, and never emergency numbers, short codes, premium-rate or personal (70) numbers. When a conversation is refused, the refusal says why, and nothing is dialled.
From your own system it is one request, with the `conversation:dial` scope and a required `Idempotency-Key`, so the same key never rings a number twice. At most 10 conversations a minute per account and 3 per key; the refusal carries `Retry-After`. The answer comes as soon as the phone starts ringing.
curl https://api.wetalk.io/v1/agents/$AGENT/outbound-conversations \
-X POST \
-H "Authorization: Bearer $WETALK_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: 0199f1c2-6b47-7c69-a3aa-8f6a1b92d487" \
-d '{ "party_number": "+302101234567", "caller_id_phone_number_id": "0199f1c2-6b48-7d7a-b4bb-906b2ca3e598", "ring_second": 30, "reference": "Order 1042" }' {
"data": {
"conversation_id": "0199f1c2-6b49-7e8b-85cc-a17c3db4f6a9",
"state": "dialing"
}
} curl https://api.wetalk.io/v1/outbound-conversations/$CONVERSATION \
-H "Authorization: Bearer $WETALK_API_KEY"
curl https://api.wetalk.io/v1/outbound-conversations/$CONVERSATION/end \
-X POST \
-H "Authorization: Bearer $WETALK_API_KEY" HD voice, honestly
WeTalk offers wideband G.722 first and falls back to G.711. “HD first” offers G.722, then G.711 µ-law and A-law; “HD, else A-law only” keeps a European A-law trunk to G.722 and A-law. HD is only heard when your provider and every network between it and the other phone carry G.722.
HD voice depends on your provider and on the other end. Conversations with ordinary phone numbers are usually standard quality (G.711, 8 kHz), because most phone networks are. WeTalk shows what each conversation actually used.
A conversation's History shows the codec that was actually used — “HD (G.722, 16 kHz)”, “Standard (G.711 A-law, 8 kHz)” or “Standard (G.711 µ-law, 8 kHz)” — and “Codec not reported” when WeTalk's SIP edge did not report one, never a guess. The trunk's recent SIP activity shows it too.
Opus is not offered over SIP. WeTalk uses Opus for browser voice — the test in the console and voice in the website widget — which never travels over your trunk.
For encryption, “If the provider offers it” encrypts the audio (SRTP) when your provider supports it, and “Always — needs TLS” never sends it unencrypted; it needs TLS because the audio keys travel in the signalling. The trunk card shows what the last conversation actually used.
Recent SIP activity
Each trunk card lists its recent SIP activity: incoming and outgoing calls, final responses, answers, hang-ups, connection checks, refused sign-ins and calls to numbers that are not on the trunk, with the time, the SIP response and the codec. The other party's number is masked. A row WeTalk recorded itself, rather than observed from your provider, is labelled “recorded by WeTalk”.
curl https://api.wetalk.io/v1/sip-trunks/$TRUNK/events \
-H "Authorization: Bearer $WETALK_API_KEY" Ask WeTalk for a number
If you have no provider of your own, name the agent that should answer, the country, and anything we should know — a number you already own and want to keep, for example. The request is written to your audit log. `state` is derived when you read it: `connected` once a number is bound to that agent at or after the request, with the number in `connected_e164`; `pending` until then.
curl https://api.wetalk.io/v1/numbers/requests \
-X POST \
-H "Authorization: Bearer $WETALK_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "voice_agent_id": "'$AGENT'", "country": "GR", "note": "Keep our shop number if possible" }' curl https://api.wetalk.io/v1/numbers/requests \
-H "Authorization: Bearer $WETALK_API_KEY" Numbers we issue
One list covers the whole workspace, including numbers with nothing bound to them — which is exactly the row you open this screen to fix. Availability is a separate read because whether WeTalk can issue a number today is a fact about WeTalk, not about your account.
Region and round-trip latency are measured by us and reported per region, so the figure beside a number is a measurement rather than a marketing claim.
curl https://api.wetalk.io/v1/numbers \
-H "Authorization: Bearer $WETALK_API_KEY"
curl https://api.wetalk.io/v1/numbers/availability \
-H "Authorization: Bearer $WETALK_API_KEY"
curl https://api.wetalk.io/v1/numbers/region-latency \
-H "Authorization: Bearer $WETALK_API_KEY" The older per-agent SIP credential
Agents set up before self-service trunks may still have a SIP credential of their own, read at `GET /v1/agents/{voice_agent_id}/sip` and rotated at `POST /v1/agents/{voice_agent_id}/sip/rotation`. Those routes remain for them and are legacy: that credential is not a trunk of yours, and new connections use “Connect a trunk” on Numbers & SIP.
Your own provider's webhook
Not open yet. The hooks hostname a provider would call is not live, so there is no inbound webhook address to give you; calls reach your agent through your own SIP trunk or on a number WeTalk sets up.
Calling from a browser
Voice in a browser works in two places: the test in the console and voice in the website widget. Both use WebRTC, with the Opus codec.
There is no browser endpoint or client library for your own app yet, so there is no snippet here. Voice from your own system arrives over a number or your SIP trunk, and web chat arrives over the web-chat medium.