3CX Webhook
A plugin for PBX 3CX that allows you to generate webhook events. The plugin allows you to implement integration with many CRM or Service Desk systems
- Ringing, agent's response, call ending, MP3 record
- GET methods (POST for MP3 URL)
- Does not depend on the client application
- User state history
- Windows and Debian
- 3CX Webhook documentation
Ringing
The event is generated when a call is received in the PBX
Queue
It generates events of the call passing through the PBX
3CX MP3 Records
Get a URL to download an mp3 records from your server
Picking up the phone
Employee response event to an incoming call
Missed calls
The event of a missed call by an employee or from a queue
Outgoing
Employee outgoing call event
3CX WebHook Generator
Incoming call DID 420223003090 IVR 800
Queue 802
Agent 102 receives a call
Agent 102 picked up the phone
Call ends
Few moments later
"FILES": ["https://fqdn.my3cx.eu:5001/webapi/recording/220726170922_4-1-1.mp3" ]
}
Pricing 3CX Webhook
Pricing is based on the number of concurrent calls required (SC). This includes internal and external calls 3CX.
Webhook Generator 4 SC
$ 179Webhook Generator 8 SC
$ 239Webhook Generator 16 SC
$ 359Webhook Generator 24 SC
$ 479Webhook Generator 32 SC
$ 599Webhook Generator 48 SC
$ 719Webhook Generator 64 SC
$ 959Webhook Generator 96 SC
$ 1 199Webhook Generator 128 SC
$ 1 679Webhook Generator 192 SC
$ 2 159Webhook Generator 256 SC
$ 2 399Webhook Generator 512 SC
$ 3 599Webhook Generator 1024 SC
$ 4 799
- The price doesn’t include any taxes or VAT
- Annual licenses
Technical features
You will need to install an additional service on the OS (Debian or Windows)
The “webhooks” module is used to integrate 3CX with third-party CRM systems. It is written in C #, implemented as a service and connects to 3CX at the time of start. As a result, the module continuously monitors the low-level telephone exchange activity and on this basis of monitoring generates a high-level events occur:
- ringing
- call start
- call end
3CX Webhook generator sends at the moment of each of the events https-request (webhook) on the address specified in the .ini file with certain data about the call.
Note: if an extension’s phone range, and then stopped ringing, but the call did not end (went to another extension), then there is no such event (the extension’s phone stopped ringing, but the call did not end).
Description of the data that is transmitted via webhooks when events occur
Сall initialization
- event = ringing/dialing
- callerid = Caller ID
- did = external number the call was received from (incoming DID rule)
- user = user extension
- usertype = ext/queue/other
- id = unique call id (string value). If a call has come to the queue and the phone is sequentially or simultaneously ringing for several managers, then they will all have the same id.
Call started
- event = hangupincoming / hangupoutgoing (Incoming or outgoing call)
- callerid = External number participating in the conversationExtension
- user =participating in the conversation
- did = If the call is incoming, then the external number that received the call (DID- rule)
- trtype = NotDef / Blind / Accomp (How the call was received: 1) a regular call, 2) a call received through a blind transfer, 3) a call received through an accompanying transfer)
- Id = Unique call id (string value) The
Call ended
- event = incoming / outgoing
- callerid = External number
- user = Internal number. If the call is missed, and it ended at the queue level, then this will be the queue extension
- finishtype = Ok / Missed (How the call ended: successful (there was a conversation) or unsuccessful (i.e. when an outgoing call was called, but the other end did not picked up the phone, and when the call came in, no one answered the call on the 3CX side))
- transfer = false / true (Did the call end completely, or went through the transfer to another extension)
- title = As a phrase, detailed information about the call, which, in addition to the above includes: a) the name of the DID rule for an incoming call; b) if the call ended at the queue level, was a callback ordered; c) call duration
- id = Unique call id (string value) The
call ID is formed as follows:
[date time]_[unique call number within the current 3CX session]-[call link number]
Example ID: 210701165649_698-2
Date and time correspond to the moment when the call arrived at the 3CX. A call link is a sequence number of a call in a single chain of transfers. When a call has just arrived at the PBX, and no one has answered it yet, the call link is equal to 0. As soon as someone answers, it is equal to 1. For each subsequent transfer, the call link is increased by 1. All calls in a single transfer chain have a date time and a unique number within the current session are the same. Such calls differ only in the link number.
Example:
https://webhook.site/?event=ringing&callerid=420774852629&user=106&usertype=other&did=PragueDID&id=211230100614_665-0
https://webhook.site/?callerid=420774852629&event=hangupincoming&user=106&did=PragueDID&trtype=NotDef&id=220106205945_755-1
After the complete end of the call (when the external subscriber hangs up), a recording of the conversation appears in 3CX, or several recordings of conversations that correspond to the entire chain of transfers, if any. Recordings of conversations appear with a slight delay: from a few milliseconds to 1-2 seconds after hanging up. As soon as this happens, the “webhooks” module converts the wav-file (s) with the recording (recordings) into mp3-format and places them in a separate folder, from which it is possible to download recordings via an https-link. The link to download the files is sent via the corresponding POST request. Thus, a webhook with information about the end of the call and a webhook with a link to the conversation file are different, separate webhooks.
In a POST request, in the general case, several links can be sent to download a conversation recording. The fact is that in 3CX one conversation can correspond to several sound files. This happens if they spoke through a mobile application, and during the conversation, the connection was lost for a short time. In this case, each short-term disconnection is the beginning of a new record file.
In addition to the link to the conversation record, the POST request contains a call id, by which it can be identified with the call start / end events. Optionally (via an ini file) in the POST request, you can enable the transfer of complete information about the ended call. In this case, the POST request will contain the same information (besides the link to download the record) as the call termination event.
Records of conversations in mp3 format are stored in a separate package for the required number of days (the corresponding parameter is set in the ini-file of the service). At night, records that have expired are automatically deleted by the service.
Example:
{"FILES":["https://3CXFQDN:5001/webapi/recording/211230102738_669-1-1.mp3"]}1. Create a separate database on the same 3CX instance (dbname with dbpassword)
2. Create table
— Table: public.operator_state_history
— DROP TABLE IF EXISTS public.operator_state_history;
CREATE TABLE IF NOT EXISTS public.operator_state_history
(
date timestamp with time zone,
old_values text COLLATE pg_catalog.”default”,
new_values text COLLATE pg_catalog.”default”,
ext text COLLATE pg_catalog.”default”
)
WITH (
OIDS = FALSE
)
TABLESPACE pg_default;
ALTER TABLE IF EXISTS public.operator_state_history
OWNER to phonesystem;
3. Specify the following in the TCXWebAPI.ini
DBS_NAME = dbname
DBS_PORT = 5480
DBS_LOGIN = phonesystem
DBS_PASSWORD =dbpassword
DBS_TABLE = public.operator_state_history
4. Select user history
SELECT date, old_values, new_values, ext
FROM public.operator_state_history