1 1. Stakeholders & Status
2 2. Business Requirement
3 3. Current Webhook Configurations
- 3.1 Scenario 1: Static Endpoint URL
- 3.2 Scenario 2: Dynamic Endpoint URL
  - 3.2.1 Sample Custom JSON
4 4. Potential Enhancement
- 4.1 1. Ease of Configuration
- 4.2 2. Flexibility in Data Handling
- 4.3 3. Reduces Manual Errors
- 4.4 4. Enhances Scalability
5 5. Confidentiality

1. Stakeholders & Status

1	Document Owner	@Mahesh Bhosale
2	Document Reviewer
3	Document Status	status:IN PROGRESS

2. Business Requirement

The webhook integration is required to enable seamless communication between the Admin UI and external systems. The webhook should support both static and dynamic endpoint URLs, allowing flexible configurations based on business needs. This integration will help in automating data exchange and triggering external actions based on system events.

3. Current Webhook Configurations

Scenario 1: Static Endpoint URL

If a webhook URL is configured under the Setup section of the Admin UI, the endpoint URL remains static. The Body Type can be selected as either:

NONE (default payload)
JSON / FORM_DATA / URL_ENCODED (custom payload)

Scenario 2: Dynamic Endpoint URL

If the endpoint URL needs to be dynamic (i.e., unique for each request), it must be configured directly within the webhook widget.

In this case, we need to:

Select Webhook Type as CUSTOM
Define the Method and URL (using a flow key variable)
Configure Authentication (if applicable)
Define a custom payload in JSON / XML / FORM_DATA / PLAIN_TEXT
Specify variables for each header, from which values will be dynamically fetched

Unlike the static endpoint configuration, this approach does not provide a direct option to select the query parameters to be passed in the payload. Instead, these must be defined explicitly within the request configuration.

Sample Custom JSON

{
    "flowStatus": "COMPLETED",
    "phonon-uuid": "$flow.syskey.phonon_uuid",
    "method": "POST",
    "callDetails": [
        {
            "cdrId": "$call.cdr",
            "startTime": "$call.start",
            "connectTime": "$call.connect",
            "endTime": "$call.hangup",
            "calleeNumber": "$call.dnis.number",
            "didNumber": "$call.cli.number",
            "hangupCause": "$call.isdn",
            "duration": "$call.duration"
        }
    ],
    "keys": [
        {
            "name": "$flow.key.accountID",
            "value": "6781"
        },
        {
            "name": "$flow.key.Request_ID",
            "value": "$flow.syskey.request_id"
        },
        {
            "name": "$flow.key.call_duration_secs",
            "value": "$call.duration"
        },
        {
            "name": "$flow.key.Phonon_UUID",
            "value": "$flow.syskey.phonon_uuid"
        },
        {
            "name": "$flow.key.r_Unique_Ref_No",
            "value": "$flow.key.Unique_Ref_No"
        },
        {
            "name": "$flow.key.r_attempt_detail",
            "value": "$flow.key.attempt_detail"
        },
        {
            "name": "$flow.key.r_Convin_Call_ID",
            "value": "$flow.key.Convin_Call_ID"
        },
        {
            "name": "$flow.key.r_Name",
            "value": "$flow.key.Name"
        },
        {
            "name": "$flow.key.r_attempt_detail_id",
            "value": "$flow.key.attempt_detail_id"
        }
    ]
}

4. Potential Enhancement

When configuring custom webhooks, having a direct option to select query parameters within the payload configuration is essential for the following reasons:

1. Ease of Configuration

Eliminates the need for manually defining query parameters within the webhook request.
Reduces complexity, especially for non-technical users configuring the webhook.

2. Flexibility in Data Handling

Allows users to easily choose which parameters should be included in the payload.
Ensures consistency in how data is passed to external systems.

3. Reduces Manual Errors

Manual entry of query parameters increases the risk of misconfiguration.
A direct selection option minimizes the chances of missing or incorrectly formatted parameters.

4. Enhances Scalability

When integrating with multiple endpoints, a structured selection approach ensures uniformity.
Makes it easier to manage webhook configurations across different processes.

5. Confidentiality

This document has been developed by Phonon.io for the sole and exclusive use of the customer / prospective customer with whom this document is being shared. Further, this document has been provided by Phonon.io to the recipient in good faith and based on a request from the recipient for the same. This document is a confidential document and contains confidential product technology, workflow, and commercial details that are for the sole usage of the intended recipients of this document. Recipients are advised not to share this document with any third party that is not the intended recipient of this document and neither to bring this document in full or parts into the public domain. Any unauthorized access may be brought to Phonon.io’s notice immediately. Phonon.io is free to take any legal action it deems necessary against any person or entity that violates this confidentiality agreement. Phonon.io is bound and governed by the rules of the state of Gujarat in India. In case you are not in agreement with the terms set in this clause or are not an intended recipient of this document, please destroy the document and intimate us of the same at responsibledisclosures@phonon.io

Phonon Software

Central Webhook Configuration Scenarios