Webhook Integration

Easy Calling can invoke external HTTP endpoints (“webhooks”) during the call lifecycle. These are used to integrate with external systems (e.g., ticketing, CRM, analytics, custom automations).

This document is intended for external developers integrating their services with Easy Calling.

Overview

Easy Calling supports call event notifications to a webhook URL configured per Voice App:

  • Begin-call notification (call started)

  • End-call notification (call completed)

Events

Begin-call notification

What it represents

  • A call has been created/answered by the system and is now active within the Easy Calling lifecycle.

When it is sent

  • Near the beginning of call processing, shortly after the call record has been created.

Configuration key

  • BeginCallEventProcessingUrl

End-call notification

What it represents

  • A call has ended (terminated/completed). The payload includes the final call state as known to Easy Calling at the time of sending.

When it is sent

  • During termination processing after the call is considered ended.

Configuration key

  • EndCallEventProcessingUrl

Request format

  • Method: POST

  • Content-Type: application/json

  • Body: a JSON object representing the call record.

Delivery expectations

Because call processing can be distributed and events can be retried upstream of your service, your webhook handler should be:

  • Idempotent: handle potential duplicates using a stable key such as activeCallId (and/or correlationId).

  • Fast: respond with 2xx quickly and enqueue work for asynchronous processing.

  • Tolerant: ignore unknown fields and handle missing optional fields.

Success / failure

  • A 2xx response is treated as success.

  • A non-2xx response is treated as failure.

Payload

The webhook payload is a JSON representation of the Easy Calling call record.

Notes:

  • Field names and presence can vary by call type and configuration.

  • Additional fields may be added over time; consumers should ignore unknown fields.

  • The payload may contain personally identifiable information (PII). Handle it accordingly.

CallType

CallType is an integer that describes the overall classification of the call. Treat this as an enum value:

Known values:

Value
Meaning

0

GenericCall

1

AnsweredCall

2

MissedCall

3

InitialAnsweredCall

4

ActiveCall

5

VoiceMail

6

CallTransfered

7

CallAnsweredManually

8

OutboundCall

Forward-compatibility:

  • Do not hard-fail on unknown CallType values; new values may be introduced.

  • If you build routing/analytics based on CallType, prefer a safe default branch for unknown values.

Example payload (dummy data)

This is a real-world payload structure filled with dummy data. Values like phone numbers, tenant IDs, app IDs, names, and emails are fictitious.

Notes:

  • Use ActiveCallId (and/or CorrelationId) for idempotency/deduplication.

  • Fields starting with _ are internal metadata and should be treated as optional.

Security guidance

  • Only accept requests over HTTPS.

  • Validate the sender using an agreed mechanism (e.g., shared secret header, request signing, mTLS) based on your deployment.

  • Treat payload data as sensitive and apply appropriate retention and access controls.

Last updated