16.1 Overview

The CRM Integrations section allows AIUNIFY Call Center customers to send call center activity to an external CRM, marketing platform, automation tool, database, or custom business application.

The integration works through webhooks.

A webhook is an automated HTTP request sent from AIUNIFY Call Center to an external web address when a selected event occurs.

Examples include:

1. A call is completed
2. AI identifies a qualified lead
3. A new contact is added
4. Contact information is updated
5. A campaign begins
6. A contact presses a telephone keypad option

When one of these events occurs, AIUNIFY Call Center prepares the relevant event data and sends it as a JSON payload to the customer’s configured webhook URL.

CRM Integrations can help a business:

1. Keep an external CRM updated
2. Send qualified leads to a sales pipeline
3. Record completed calls
4. Create external tasks
5. Trigger marketing automations
6. Notify staff of important activity
7. Store call information in another system
8. Update contact records
9. Connect custom applications
10. Build reporting workflows outside AIUNIFY Call Center

16.2 Understanding the Direction of the Integration

The current CRM Integration feature sends information out of AIUNIFY Call Center.

The normal data direction is:

AIUNIFY Call Center sends an HTTP POST request containing JSON data.

The external system receives the information and decides what to do with it.

For example, the receiving system may:

1. Create a lead
2. Update a contact
3. Create a task
4. Record a call
5. Start an email automation
6. Notify a sales representative
7. Add data to a spreadsheet
8. Store information in a database

16.3 What CRM Integrations Do Not Currently Do

The current webhook feature is not a complete bidirectional synchronization system.

It does not automatically:

1. Import contacts from an external CRM
2. Pull external opportunities into AIUNIFY Call Center
3. Synchronize every CRM field in both directions
4. Resolve duplicate external records
5. Display an external CRM pipeline inside AIUNIFY
6. Create native OAuth connections to every CRM
7. Automatically map custom fields through the customer interface
8. Continuously compare two databases

When this manual uses the term “CRM synchronization,” it refers primarily to forwarding AIUNIFY events to an external system.

An external CRM may require:

1. A custom webhook receiver
2. An automation platform
3. Middleware
4. A serverless function
5. Custom API development

The external system must be capable of receiving an authenticated JSON POST request.

16.4 Supported External Systems

AIUNIFY Call Center uses a generic webhook structure rather than requiring one specific CRM.

This means it may connect with:

1. CRM platforms
2. Marketing automation platforms
3. Sales pipeline systems
4. Customer support platforms
5. Workflow automation tools
6. Business databases
7. Internal company applications
8. Serverless functions
9. Custom APIs

The receiving platform must provide or support a webhook endpoint.

A platform name alone is not enough. The Customer must obtain the correct receiving URL and authentication credentials.

16.5 Requirements Before Creating an Integration

Before setting up a CRM Integration, confirm that the Customer has:

1. An active AIUNIFY Call Center account
2. Permission to manage integrations
3. Access to the receiving CRM or external system
4. A valid webhook URL
5. An endpoint that accepts HTTP POST requests
6. Support for JSON request bodies
7. Authentication credentials when required
8. Permission to create integrations in the external system
9. A method for reviewing received data
10. A test environment when possible
11. An understanding of the data being forwarded

A technical administrator or developer may be required when the external CRM does not provide a simple incoming-webhook feature.

16.6 Opening CRM Integrations

To open the integration section:

1. Sign in to AIUNIFY Call Center.
2. Open the main navigation menu.
3. Locate Integrations or CRM Integrations.
4. Select CRM Integrations.

The main page is located at:

Only integrations belonging to the signed-in Customer account should appear.

16.7 Understanding the Integrations Page

The CRM Integrations page displays configured webhook connections.

The page may include summary measurements such as:

1. Total Integrations
2. Active Integrations
3. Webhooks Sent
4. Successful Webhooks
5. Failed Webhooks
6. Success Rate
7. Webhooks Sent During the Last 24 Hours

Each integration may appear as a separate card containing its settings, activity, and management controls.

16.8 Understanding Total Integrations

Total Integrations represents the number of CRM Integration records owned by the signed-in Customer.

This total may include:

1. Active integrations
2. Inactive integrations
3. Integrations with successful activity
4. Integrations with errors
5. Newly created integrations that have not yet been triggered

Deleting an integration reduces this total.

16.9 Understanding Active Integrations

Active Integrations represents the connections currently enabled to receive matching events.

An integration must be active before normal qualifying events are forwarded to it.

An inactive integration remains stored but is excluded from event delivery.

Use inactive status when:

1. Testing is incomplete
2. Credentials are being rotated
3. The external CRM is undergoing maintenance
4. The endpoint is temporarily unavailable
5. The workflow is no longer needed but may be restored
6. The Customer wants to preserve the configuration

16.10 Understanding Webhooks Sent

Webhooks Sent represents the number of delivery-attempt records associated with the Customer’s integrations.

A delivery attempt is logged when AIUNIFY Call Center sends an event payload to an endpoint.

This total may include both:

1. Successful deliveries
2. Failed deliveries

It should not be interpreted as a count of successfully created CRM records.

The external system determines whether it ultimately created or updated a record after receiving the webhook.

16.11 Understanding Success Rate

Success Rate is calculated by comparing successful webhook attempts with total webhook attempts.

The formula is:

For example:

The percentage is normally rounded to two decimal places.

A high delivery success rate confirms that the receiving endpoint usually returns an HTTP success response.

It does not guarantee that every external CRM action was completed correctly after the response.

16.12 Opening the Add Integration Page

To create an integration:

1. Open CRM Integrations.
2. Click Add Integration, Create Integration, or the applicable connection button.

The creation page is located at:

The form includes:

1. Integration name
2. Webhook URL
3. Events to forward
4. Authentication method
5. Authentication credentials
6. Active or inactive status

16.13 Naming the Integration

The Name field identifies the connection inside AIUNIFY Call Center.

The name is required and can contain up to 100 characters.

Use a name that identifies both the destination and purpose.

Examples include:

Avoid generic names such as:

Clear names make delivery logs and errors easier to review.

16.14 Entering the Webhook URL

The Webhook URL is the destination where AIUNIFY Call Center sends event data.

The URL is required and may contain up to 500 characters.

A webhook URL should resemble:

The destination must:

1. Be a valid URL
2. Be reachable from the internet
3. Accept HTTP POST requests
4. Accept JSON data
5. Return an HTTP response
6. Support the selected authentication method
7. Respond within the allowed timeout

Copy the URL directly from the external CRM or integration system.

Do not guess the endpoint address.

16.15 Using HTTPS

Production webhook URLs should use HTTPS.

HTTPS protects data while it travels between AIUNIFY Call Center and the external system.

Avoid production URLs beginning with:

Use:

The destination must have a valid SSL certificate.

Webhook delivery can fail when the destination certificate is:

1. Expired
2. Self-signed
3. Issued for another domain
4. Missing part of its certificate chain
5. Rejected by the server environment

16.16 Endpoint Availability

The endpoint must remain publicly accessible when AIUNIFY events occur.

A webhook may fail when the destination is:

1. Running only on localhost
2. Restricted to a private company network
3. Blocked by a firewall
4. Protected by an unsupported login page
5. Offline
6. Under maintenance
7. Using an invalid domain
8. Rejecting the AIUNIFY server
9. Responding too slowly

A private development address such as the following will not normally work from a production server:

Use a publicly accessible HTTPS endpoint.

16.17 Selecting Events to Forward

At least one event must be selected.

The available events are:

1. Call Completed
2. Lead Qualified
3. Contact Added
4. Contact Updated
5. Campaign Started
6. DTMF Response

An integration receives only the events selected in its configuration.

For example, an integration subscribed only to Contact Added will not receive Call Completed events.

Multiple events can be selected for one integration.

The same event can also be sent to multiple active integrations.

16.18 Call Completed Event

The Call Completed event is triggered after an eligible call ends.

Its event identifier is:

The payload may include information such as:

1. Call ID
2. Contact information
3. Telephone number
4. Call direction
5. Call status
6. Call duration
7. Campaign information
8. Transcript information
9. Sentiment results
10. Detected intent
11. Call timestamps
12. Other available call details

Use this event to:

1. Create call-history records in a CRM
2. Update a sales activity timeline
3. Notify a supervisor
4. Store transcripts externally
5. Start a post-call workflow
6. Create follow-up tasks

The exact payload fields depend on the call record and available analysis.

16.19 Lead Qualified Event

The Lead Qualified event is triggered when AIUNIFY Call Center identifies an eligible qualified or high-interest lead.

Its event identifier is:

Qualification may be based on available information such as:

1. Positive sentiment
2. Conversation quality
3. Detected interest
4. Lead score
5. AI analysis
6. Call outcome
7. Intent recognition

Use this event to:

1. Create a sales opportunity
2. Notify a sales representative
3. Move a lead into a higher-priority pipeline
4. Start an external follow-up automation
5. Send lead data to another business system

The external CRM should have a process for handling duplicate qualification events.

16.20 Contact Added Event

The Contact Added event is triggered when a new contact is created or imported.

Its event identifier is:

The payload may include:

1. Contact ID
2. First name
3. Last name
4. Telephone number
5. Email address
6. Company
7. Website
8. Address information
9. Social media information
10. Contact status
11. Creation date
12. Other stored contact fields

Use this event to:

1. Create the contact in another CRM
2. Add the contact to a marketing list
3. Create an external customer profile
4. Start an onboarding workflow
5. Notify a team member

Review duplicate-record rules in the receiving system before activating this event.

16.21 Contact Updated Event

The Contact Updated event is triggered when an existing contact’s information changes.

Its event identifier is:

Use this event to forward changes involving:

1. Name
2. Telephone number
3. Email address
4. Company
5. Website
6. Address
7. Social profiles
8. Status
9. Other stored contact information

The receiving system must decide which external contact should be updated.

AIUNIFY Call Center does not provide a full customer-facing external field-mapping interface in the current release.

The external workflow may need to match records using:

1. AIUNIFY contact ID
2. Telephone number
3. Email address
4. External reference
5. Another unique identifier

16.22 Campaign Started Event

The Campaign Started event is triggered when an eligible campaign begins.

Its event identifier is:

The payload may include:

1. Campaign ID
2. Campaign name
3. Campaign status
4. Start time
5. Assigned number
6. Contact counts
7. Campaign settings
8. Other available campaign information

Use this event to:

1. Notify a sales team
2. Create an external campaign record
3. Start a related marketing workflow
4. Update an operations dashboard
5. Record the campaign launch time
6. Alert a manager

16.23 DTMF Response Event

DTMF means Dual-Tone Multi-Frequency.

It refers to telephone keypad presses made during a call.

The DTMF Response event identifier is:

Examples include:

1. Press 1 for Sales
2. Press 2 for Support
3. Press 3 to request a callback
4. Press 9 to opt out

The payload may contain:

1. Call information
2. Contact information
3. Key pressed
4. Campaign information
5. Time of response
6. Configured action
7. Other available call data

Use this event to:

1. Update contact intent
2. Record menu selections
3. Create a callback request
4. Notify the correct department
5. Start an external automation
6. Record an opt-out request

DTMF responses should be interpreted according to the campaign’s configured keypad actions.

16.24 Choosing the Correct Events

Select only events the external system is prepared to process.

Forwarding unnecessary events can:

1. Create duplicate records
2. Increase external automation usage
3. Produce excessive notifications
4. Increase storage requirements
5. Make delivery logs harder to review
6. Expose more information than necessary

For example, a qualified-lead workflow may require only:

A complete CRM activity integration may require:

Review the business purpose before enabling all available events.

16.25 Authentication Methods

AIUNIFY Call Center supports four authentication methods:

1. None
2. Bearer Token
3. API Key
4. HMAC Signature

The authentication method determines how the receiving system verifies that a request came from an authorized sender.

Select the method required by the destination endpoint.

16.26 No Authentication

The None option sends the webhook without an authentication credential.

Use None only for:

1. Temporary testing
2. A protected internal testing environment
3. A temporary webhook inspection endpoint
4. An endpoint protected through another secure control

None is not recommended for a public production endpoint.

Without authentication, an outside party could potentially imitate requests to the same URL.

16.27 Bearer Token Authentication

Bearer Token authentication sends a secret token in the request’s Authorization header.

It generally follows this structure:

Bearer authentication is commonly used by modern APIs and CRM platforms.

To use it:

1. Obtain the token from the receiving platform.
2. Select Bearer Token.
3. Enter the token in the authentication field.
4. Save the integration.
5. Test the connection.

Treat the token like a password.

16.28 API Key Authentication

API Key authentication sends a secret key in a designated request header.

A common example is:

The exact header and credential requirements depend on the receiving system and the fields presented in the integration form.

To use an API key:

1. Create or obtain the key from the external system.
2. Confirm the required header name.
3. Select API Key.
4. Enter the required credentials.
5. Save and test the integration.

Do not confuse an AIUNIFY API key with the external system’s incoming-webhook API key.

16.29 HMAC Signature Authentication

HMAC provides cryptographic verification of the webhook payload.

Instead of relying only on a reusable token, AIUNIFY Call Center uses a shared secret to generate a signature from the payload.

The receiving endpoint independently generates the expected signature and compares it with the supplied signature.

HMAC can help verify:

1. The request was created by a party holding the secret
2. The payload was not changed while being delivered
3. The request timestamp is acceptable

To use HMAC:

1. Create a strong shared secret.
2. Store the secret securely in the receiving application.
3. Select HMAC Signature.
4. Enter the same secret in AIUNIFY Call Center.
5. Configure the receiver to calculate and compare signatures.
6. Validate the timestamp.
7. Test the integration.

16.30 Current HMAC Header Names

The current source sends the HMAC information using these headers:

Although the platform is branded as AIUNIFY Call Center, the current webhook code retains the original X-Teleman header names.

The receiving endpoint must check the actual headers sent by the current implementation.

Do not rename the expected headers in the external receiver unless the AIUNIFY application code has also been updated.

16.31 Protecting Authentication Credentials

CRM credentials should be handled as sensitive information.

Do not place tokens, keys, or HMAC secrets in:

1. Public documentation
2. Screenshots
3. Shared spreadsheets
4. Source-code repositories
5. Public support tickets
6. Unsecured email
7. Group chats
8. Training demonstrations

If a credential is exposed:

1. Disable or rotate it in the external system.
2. Update the AIUNIFY integration.
3. Test the new credential.
4. Review delivery logs for suspicious activity.
5. Remove the exposed value from documents and messages.

The integration model hides stored authentication credentials from normal output, but users must still protect them during entry and external-system management.

16.32 Activating the Integration

The Active control determines whether the integration receives live events.

Active

Matching events are eligible for delivery.

Inactive

The integration remains stored but no new matching events are sent through normal event dispatch.

A recommended setup process is:

1. Create the integration as inactive.
2. Verify the webhook URL.
3. Verify authentication.
4. Run a test.
5. Review the receiving system.
6. Activate the integration.
7. Monitor the first live event.

16.33 Saving the Integration

Before saving, verify:

1. The integration name
2. The webhook URL
3. The selected events
4. The authentication method
5. Authentication credentials
6. Active or inactive status
7. Endpoint readiness
8. Data privacy requirements

Click Save, Create Integration, or the applicable button.

The system validates that:

1. A name is present
2. The name does not exceed 100 characters
3. A valid URL is present
4. The URL does not exceed 500 characters
5. At least one supported event is selected
6. The authentication method is valid

16.34 Testing the Integration

Each integration includes a Test control.

To test:

1. Open CRM Integrations.
2. Locate the integration.
3. Click Test.
4. Wait for the result.
5. Review the success or failure message.
6. Check the receiving system.

The test sends a sample webhook payload to the configured endpoint.

A successful test confirms that AIUNIFY received an acceptable response.

It does not guarantee that every live event field has been mapped correctly in the external CRM.

16.35 Recommended Test Procedure

Use the following process:

1. Create a test endpoint or test workflow.
2. Configure authentication.
3. Create the AIUNIFY integration.
4. Keep it inactive if possible.
5. Click Test.
6. Review the request headers.
7. Review the JSON payload.
8. Confirm the authentication result.
9. Confirm the response code.
10. Confirm the external system recorded the test.
11. Activate the integration.
12. Generate one controlled live event.
13. Review the delivery log.
14. Confirm the external record.

Do not activate a high-volume integration before completing a controlled test.

16.36 Understanding the Webhook Payload

Webhook payloads are sent as JSON.

A simplified payload may resemble:

The exact fields vary according to the event.

Every payload includes information identifying:

1. The event type
2. The integration
3. The relevant event data

The external receiver should not assume that every event contains the same fields.

16.37 Designing the Receiving Endpoint

The receiving endpoint should:

1. Accept HTTP POST requests
2. Accept JSON content
3. Validate authentication
4. Validate the event field
5. Validate required data
6. Safely handle missing optional fields
7. Prevent duplicate processing
8. Store or process the event
9. Return an HTTP response promptly
10. Log errors internally
11. Protect sensitive information

The receiver should not require a human login page.

It should be an API or webhook endpoint.

16.38 Response Time Limit

The AIUNIFY webhook request uses a 30-second timeout.

The receiving endpoint should respond well before 30 seconds.

A better workflow is:

1. Receive the webhook.
2. Validate it.
3. Store or queue the event.
4. Return a successful response.
5. Perform lengthy processing in the external system’s background worker.

Avoid performing a long CRM import or complex analysis before returning the HTTP response.

16.39 Successful HTTP Responses

AIUNIFY treats response codes from 200 through 299 as successful.

Common successful responses include:

HTTP 200 — OK

The webhook was received and processed.

HTTP 201 — Created

The external system created a new resource.

HTTP 202 — Accepted

The event was accepted for background processing.

HTTP 204 — No Content

The event was accepted, and no response body is required.

The external endpoint should return a 2xx response only after it has accepted responsibility for the payload.

16.40 Failed HTTP Responses

Responses outside the 200–299 range are treated as failed deliveries.

The integration may record:

1. HTTP status
2. Response body
3. Event type
4. Payload
5. Trigger time
6. Last error

The integration card may display the most recent error.

Review the delivery logs for additional details.

16.41 Understanding the Integration Card

Each CRM Integration card may display:

1. Integration name
2. Active or inactive status
3. Webhook URL
4. Selected events
5. Authentication method
6. Total trigger count
7. Last triggered time
8. Last error
9. Test button
10. View Logs button
11. Edit button
12. Delete button

The Total Triggers value increases when webhook attempts are made.

The Last Triggered field shows the most recent attempt time.

16.42 Editing an Integration

To edit:

1. Open CRM Integrations.
2. Locate the connection.
3. Click Edit.
4. Update the required settings.
5. Save the changes.

The edit page may be located at:

Editable settings include:

1. Name
2. Webhook URL
3. Events
4. Authentication method
5. Authentication credentials
6. Active status

Test the integration after changing its URL or credentials.

16.43 Changing the Webhook URL

Changing the URL redirects future event deliveries to the new endpoint.

Before changing it:

1. Confirm the new endpoint is ready.
2. Configure authentication.
3. Test the new destination.
4. Confirm that the old system no longer requires events.
5. Monitor the first live delivery.

Changing the URL does not automatically transfer historical data to the new endpoint.

16.44 Changing Authentication

Authentication may need to be updated when:

1. A token expires
2. A key is rotated
3. A secret is exposed
4. The external system changes its security requirements
5. The endpoint moves to another platform
6. The business upgrades from no authentication

After changing credentials:

1. Save the integration.
2. Run the test.
3. Review the new log entry.
4. Confirm the external system accepted the request.
5. Activate the connection if it was temporarily disabled.

16.45 Deactivating an Integration

Deactivate an integration when webhook delivery should stop temporarily.

To deactivate:

1. Open the integration’s Edit page.
2. Turn off Active status.
3. Save the integration.

Deactivation is preferable to deletion when:

1. Maintenance is temporary
2. The external system is unavailable
3. Credentials are being replaced
4. The workflow may be restored
5. Configuration history should be preserved

Events occurring while the integration is inactive are not guaranteed to be delivered later.

16.46 Deleting an Integration

To delete:

1. Open CRM Integrations.
2. Locate the integration.
3. Click Delete.
4. Review the confirmation.
5. Confirm deletion.

Deleting an integration stops future event delivery to that destination.

Before deletion:

1. Record the configuration
2. Review recent logs
3. Confirm that the endpoint is no longer needed
4. Notify the external-system owner
5. Disable dependent automations
6. Preserve any information required for audits

Treat deletion as permanent through the normal customer interface.

16.47 Opening Webhook Logs

To review an integration’s activity:

1. Open CRM Integrations.
2. Locate the integration.
3. Click View Logs.

The integration-specific log page is located at:

The logs are displayed with the newest delivery attempts first.

The system normally loads log records in paginated groups.

16.48 Information Stored in a Webhook Log

A webhook log can contain:

1. Integration
2. Customer account
3. Event type
4. Payload
5. Response status
6. Response body
7. Triggered date and time

This information helps determine:

1. What was sent
2. When it was sent
3. Which integration was used
4. Whether the receiver accepted it
5. What error the receiver returned

Authentication credentials are not intended to appear in the log payload.

16.49 Successful Log Entries

A successful delivery normally displays a green status indicator.

A webhook is considered successful when its response status is between 200 and 299.

Review the response body when the external system provides confirmation information.

A green status confirms successful HTTP delivery, not necessarily a successful business result.

For example, an external endpoint could return HTTP 200 while internally ignoring the event because of incorrect mapping.

16.50 Failed Log Entries

A failed delivery normally displays a red status indicator.

A webhook is considered failed when:

1. The response status is below 200
2. The response status is 300 or higher
3. No response status was received
4. A connection exception occurred
5. The request timed out

Review:

1. Status code
2. Response body
3. Payload
4. Event type
5. Trigger time
6. Integration’s Last Error

Correct the cause before retrying.

16.51 Common HTTP Status Codes

HTTP 400 — Bad Request

The external system rejected the payload format or required fields.

Review the request body and receiving-system validation.

HTTP 401 — Unauthorized

Authentication was missing or incorrect.

Review the token, API key, or HMAC verification.

HTTP 403 — Forbidden

The credentials may be recognized but lack permission.

Review endpoint access rules, scopes, IP restrictions, and account status.

HTTP 404 — Not Found

The webhook URL does not point to a valid endpoint.

Confirm the route and domain.

HTTP 405 — Method Not Allowed

The endpoint does not permit HTTP POST.

Update the endpoint to accept POST requests.

HTTP 409 — Conflict

The external system may have detected a duplicate or conflicting record.

Review its duplicate-handling rules.

HTTP 422 — Unprocessable Content

The JSON was received but failed field validation.

Review required fields and data formats.

HTTP 429 — Too Many Requests

The external system is rate-limiting the integration.

Reduce event volume or contact the external provider.

HTTP 500 — Internal Server Error

The external endpoint encountered an application error.

Review the external system’s logs.

HTTP 502, 503, or 504

The destination server or gateway may be unavailable, overloaded, or timing out.

Wait until the destination is stable before retrying.

16.52 Manually Retrying a Failed Webhook

Failed webhook logs include a Retry control.

To retry:

1. Open the Webhook Logs page.
2. Locate the failed record.
3. Review the original status and response.
4. Correct the destination issue.
5. Click Retry.
6. Confirm the retry request.
7. Review the returned result.
8. Refresh the logs.

The system resends the stored payload to the integration’s endpoint.

16.53 Retry and Duplicate Record Risk

A retry may cause the external system to receive the same event more than once.

The receiving endpoint should use idempotent processing.

Idempotent processing means that receiving the same event twice does not create two unintended business records.

The external system may use a combination of:

1. Event type
2. AIUNIFY record ID
3. Integration ID
4. Call ID
5. Contact ID
6. Campaign ID
7. DTMF record ID
8. Stored payload hash
9. External deduplication key

Before retrying, confirm whether the original event may have been processed even though AIUNIFY received an error or timeout.

For example, the external system might create the CRM record but fail before returning its response.

16.54 Automatic and Manual Delivery Handling

CRM event listeners are designed to dispatch webhook activity through the application’s event-processing system.

The customer-facing logs provide a manual Retry function for failed entries.

Customers should not assume that a failed event will be retried indefinitely without intervention.

Review failed logs regularly and manually retry events after correcting the underlying issue.

16.55 Viewing All Webhook Logs

AIUNIFY Call Center also supports reviewing webhook logs across all Customer integrations.

The all-logs view may allow filtering by:

1. Event type
2. Integration
3. Delivery status

Available status filters may include:

Success

Displays entries with HTTP status 200–299.

Failed

Displays entries with no status or a status outside 200–299.

The default page size is normally 50 records.

16.56 Filtering by Event Type

Event filtering helps isolate a particular workflow.

For example:

1. Select Call Completed to investigate call synchronization.
2. Select Lead Qualified to review sales-lead delivery.
3. Select Contact Added to investigate missing CRM contacts.
4. Select DTMF Response to review IVR events.

Clear the filter to return to all event types.

16.57 Filtering by Integration

When the Customer has several integrations, use the Integration filter to review one destination.

This helps determine whether failures affect:

1. One external system
2. Every external system
3. One authentication method
4. One endpoint
5. One event configuration

If the same event succeeds in one integration but fails in another, the problem is likely related to the failing destination’s configuration.

16.58 Reviewing the Last Error

The integration card may display a Last Error.

The Last Error normally contains the most recent delivery problem, such as:

1. HTTP status
2. External response body
3. Connection error
4. Timeout message

After a successful webhook delivery, the system clears the stored Last Error.

A blank Last Error does not mean that no previous failures exist.

Review the complete delivery logs for historical errors.

16.59 Total Trigger Count

Each integration stores a Total Triggers value.

The counter increases when webhook attempts are made.

It can help answer:

1. Has the integration ever been triggered?
2. Is the selected event occurring?
3. Has activity recently increased?
4. Is one integration receiving more events than another?

Total Triggers does not distinguish successful and failed deliveries by itself.

Use the logs and statistics for that comparison.

16.60 Last Triggered Time

The Last Triggered time records the most recent delivery attempt for the integration.

If the value is empty, the integration may:

1. Be new
2. Be inactive
3. Have no matching events
4. Have an incorrect event selection
5. Not yet have received a test
6. Not be connected to active call center activity

Generate a controlled matching event and review the logs.

16.61 Connecting Through an Automation Platform

Some CRMs do not provide a direct incoming webhook that matches AIUNIFY’s payload.

In that case, the Customer may use an automation platform as middleware.

The flow becomes:

The automation platform can:

1. Receive the AIUNIFY JSON
2. Rename fields
3. Search for an existing record
4. Create or update a CRM record
5. Send notifications
6. Handle errors
7. Store external record IDs

The Customer is responsible for configuring and maintaining the automation workflow.

16.62 Connecting to a Custom Application

A custom application can create an endpoint specifically for AIUNIFY events.

The developer should:

1. Create an HTTPS POST endpoint.
2. Accept JSON.
3. Validate authentication.
4. Validate the event name.
5. Validate the payload.
6. Store an event identifier.
7. Prevent duplicate processing.
8. Queue lengthy work.
9. Return a 2xx response quickly.
10. Log internal failures.
11. Protect customer information.
12. Test each supported event separately.

16.63 Customer and Agent Access

CRM Integration management is intended primarily for:

1. Customer account owners
2. Customer technical administrators
3. Authorized operations managers
4. Approved integration developers

Regular calling Agents should not normally manage:

1. Webhook URLs
2. API keys
3. Bearer tokens
4. HMAC secrets
5. External CRM configuration
6. Integration deletion

Agents may generate events through their normal work, such as completing calls or updating contacts, but the Customer should control where that data is delivered.

16.64 Data Privacy Responsibilities

CRM webhooks may contain customer, prospect, call, campaign, or conversation information.

Before forwarding data, the Customer should determine:

1. What data is being sent
2. Why it is being sent
3. Where it is stored
4. Who can access it
5. How long it is retained
6. Whether consent is required
7. Whether call transcripts may be transferred
8. Whether the destination meets security requirements
9. Whether the destination operates in another country
10. Whether deletion requests can be honored

Select only the events necessary for the intended business purpose.

16.65 Troubleshooting: Integration Test Fails

Confirm:

1. The Webhook URL is correct
2. The endpoint is publicly accessible
3. HTTPS is valid
4. The endpoint accepts POST
5. The endpoint accepts JSON
6. Authentication credentials are correct
7. The firewall permits requests
8. The endpoint responds within 30 seconds
9. The external service is online

Review the returned status and response body.

16.66 Troubleshooting: HTTP 404

An HTTP 404 response means the destination route was not found.

Confirm:

1. The domain is correct
2. The path is complete
3. The webhook route still exists
4. No characters were omitted
5. The external service did not change the URL
6. The endpoint is deployed to production
7. A trailing path segment is not missing

Copy the webhook URL again from the receiving system.

16.67 Troubleshooting: HTTP 401 or 403

For a 401 or 403 response, review:

1. Authentication type
2. Token value
3. API key
4. Header name
5. Token expiration
6. Required permission scopes
7. External account status
8. IP restrictions
9. HMAC secret
10. HMAC timestamp validation

Do not repeatedly retry with known-invalid credentials.

16.68 Troubleshooting: HMAC Verification Fails

Confirm:

1. Both systems use the same secret
2. The receiver reads X-Teleman-Signature
3. The receiver reads X-Teleman-Timestamp
4. The exact raw payload is used when required
5. JSON is not modified before verification
6. The signature algorithm matches the sender
7. The timestamp is within the allowed period
8. Character encoding matches

Test with a controlled request and log the calculated signatures securely.

Do not display the shared secret in logs.

16.69 Troubleshooting: HTTP 422

An HTTP 422 response normally means the receiving system rejected one or more payload fields.

Review:

1. Required external fields
2. Field names
3. Data types
4. Telephone-number format
5. Date format
6. Email format
7. Missing identifiers
8. Unsupported status values
9. CRM field requirements

A middleware mapping layer may be needed.

16.70 Troubleshooting: HTTP 429

HTTP 429 means the receiving platform is limiting request volume.

Possible solutions include:

1. Reduce selected events
2. Use a queue in the external system
3. Request higher API limits
4. Add rate-limiting logic
5. Spread processing across time
6. Consolidate notifications
7. Upgrade the external service plan

Do not repeatedly retry large numbers of failed events without addressing the rate limit.

16.71 Troubleshooting: HTTP 500

HTTP 500 is generated by the receiving system.

Review its:

1. Application logs
2. Database connection
3. API configuration
4. Authentication handler
5. JSON parser
6. Field mapping
7. Queue service
8. Environment variables
9. External CRM credentials

The AIUNIFY log response body may provide an error message, but the main correction must occur on the destination server.

16.72 Troubleshooting: Request Times Out

The AIUNIFY request times out after approximately 30 seconds.

A timeout may occur when the destination:

1. Performs too much work before responding
2. Is overloaded
3. Has a slow database
4. Waits for another API
5. Is behind an unavailable gateway
6. Has DNS problems
7. Is blocked by a firewall

The receiving endpoint should accept the event, queue its work, and return a response promptly.

Before retrying a timeout, check whether the destination already processed the original event.

16.73 Troubleshooting: Test Works but Live Events Do Not

Confirm:

1. The integration is Active
2. At least one event is selected
3. The selected live event actually occurred
4. The event belongs to the correct Customer
5. The integration belongs to the signed-in Customer
6. Background event processing is operating
7. The relevant event listener is active
8. The Last Triggered time changed
9. The event was not generated under another account

Test success proves endpoint access, but live delivery also depends on a matching event.

16.74 Troubleshooting: No Contact Events Appear

Confirm:

1. Contact Added or Contact Updated is selected
2. The integration is Active
3. The contact belongs to the Customer account
4. A contact was actually created or updated
5. The action generated the expected application event
6. Delivery logs were refreshed
7. The endpoint did not filter out the event

Imported contacts may generate activity according to the application’s event process.

Review a manually created test contact when troubleshooting.

16.75 Troubleshooting: No Call Completed Events Appear

Confirm:

1. Call Completed is selected
2. The integration is Active
3. The call reached a completed state
4. The call belongs to the Customer account
5. Call status webhooks are functioning
6. The call record was updated
7. Background processing is operating
8. The correct integration is being reviewed

A call that remains Ringing, In Progress, Failed, or unsynchronized may not produce the expected completed event.

16.76 Troubleshooting: Duplicate CRM Records

Duplicate records may result from:

1. Manual retries
2. Repeated source events
3. Multiple integrations pointing to the same destination
4. External automation retries
5. Missing deduplication rules
6. Endpoint timeouts after successful processing
7. Contact matching based on non-unique information

Use stable identifiers such as:

1. Call ID
2. Contact ID
3. Campaign ID
4. Integration ID
5. Event type

The receiving system should check whether it has already processed the event.

16.77 Troubleshooting: Integration Shows Last Error After Repair

The Last Error remains until a later successful delivery clears it.

After repairing the connection:

1. Run Test.
2. Generate a controlled live event.
3. Confirm a 2xx response.
4. Refresh the integration page.
5. Review the latest log.

The historical failed logs remain useful even after the Last Error is cleared.

16.78 Troubleshooting: Retry Also Fails

If a retry fails:

1. Review the new response.
2. Confirm that the endpoint repair was deployed.
3. Confirm credentials were saved.
4. Confirm the integration is using the correct URL.
5. Test the destination independently.
6. Review the external server logs.
7. Avoid repeated retries until the cause is corrected.

The Retry function resends the original stored payload. It does not automatically transform the payload to meet new external validation rules.

16.79 Recommended Integration Practices

Use a descriptive integration name.

Use HTTPS.

Use authentication in production.

Select only necessary events.

Create separate integrations for unrelated workflows.

Test before activation.

Monitor logs after activation.

Review failures regularly.

Build duplicate protection into the receiver.

Return responses quickly.

Rotate credentials periodically.

Deactivate integrations during maintenance.

Delete integrations that are permanently abandoned.

Protect transcripts and contact information.

Document the destination owner and business purpose.

16.80 Security Checklist

Before activating a production integration, confirm:

1. The endpoint uses HTTPS.
2. The SSL certificate is valid.
3. Authentication is enabled.
4. Tokens and secrets are stored securely.
5. The endpoint validates every request.
6. HMAC signatures are verified when selected.
7. HMAC timestamps are checked.
8. The endpoint accepts only required methods.
9. Logs do not expose credentials.
10. Only necessary events are selected.
11. Sensitive payloads are encrypted during storage.
12. External-system access is restricted.
13. Duplicate protection is implemented.
14. Credential-rotation procedures exist.
15. Data-retention rules are documented.

16.81 Integration Readiness Checklist

Before using a CRM Integration with live business data, confirm:

1. The integration has a clear name.
2. The Webhook URL is correct.
3. The endpoint accepts POST requests.
4. The endpoint accepts JSON.
5. HTTPS is active.
6. At least one event is selected.
7. Authentication matches the receiving system.
8. Credentials are current.
9. The integration has been tested.
10. The test appears in the receiving system.
11. The integration is Active.
12. A controlled live event has been completed.
13. The live event appears in Webhook Logs.
14. The log shows HTTP 200–299.
15. The external CRM created or updated the expected record.
16. Duplicate protection is active.
17. Failed-delivery monitoring is assigned to a responsible user.
18. Data privacy requirements have been reviewed.

16.82 Chapter Summary

CRM Integrations allow AIUNIFY Call Center Customers to forward call center events to external CRMs, marketing tools, automation systems, databases, and custom applications.

The current integration is an outbound webhook system. It sends JSON data from AIUNIFY Call Center to a Customer-provided URL. It is not a complete bidirectional CRM synchronization service.

Supported events include:

1. Call Completed
2. Lead Qualified
3. Contact Added
4. Contact Updated
5. Campaign Started
6. DTMF Response

Supported authentication methods include:

1. None
2. Bearer Token
3. API Key
4. HMAC Signature

Each integration stores its selected events, active status, trigger count, last-triggered time, and last error.

Every webhook attempt is recorded in the delivery logs with its event type, payload, HTTP response status, response body, and trigger time.

HTTP 200–299 responses are treated as successful. Failed webhook records can be manually retried after the endpoint problem is corrected.

Customers should use HTTPS, protect credentials, select only necessary events, implement duplicate protection, monitor delivery logs, and carefully control how external systems store contact, call, campaign, and transcript information.