Voice agent webhooks: sending data after a call

Give the destination a clear job

When a conversation ends, the webhook sends an automatic notification to another system’s connection address. First define what that system should do: record a request, create a task or update a report. Choose information available in the current Tigy settings and keep a received request distinct from a completed action.

Do not send the entire conversation by default when the process only needs an identifier and an outcome. Agree on necessary fields with the destination system's owner.

Choose the information sent after the call

In Tigy, open the agent’s webhook options. Enter the address supplied by the integration team and select the information to send from the available variables. Payload is the technical name for that bundle of information, such as the conversation reference and reason for contact.

Agree with the destination owner on the format and sending method required by the settings. Do not copy fields from an example without checking that they are available in the panel. Make a test call and confirm what arrived in the system.

Separate receiving from processing

The destination system may receive the notification and still fail to save the record. Ask the integration owner to check processing, required information and association with the correct conversation. You can verify whether the task actually appeared in the queue staff use.

Design the receiver to recognize the same event if it appears again. This is an integration decision; do not assume delivery guarantees or retry behavior without checking them.

Follow a conversation to its destination

Run a test call, compare selected fields with the received payload and verify the expected record. Inspect receiver logs for rejected or missing requests.

Document who monitors failures and how the team recovers an unrecorded request. A webhook transports data; the next action depends on the destination process you build.

Check receipt without creating duplicate tasks

Consider a fictional callback request. When the call ends, the notification carries the conversation reference and reason for contact. Check that the destination received the information and created the task staff will actually use.

Ask the integration team to send the same notification twice during the test. There should still be one task for that request, without duplication. Then test a genuinely new request from the same customer to check it is not discarded.

Design receivers for repetition and variable order

Events may be delivered again or arrive after related events. External receivers should identify completed work and decide whether to update, ignore or investigate. Creating a new ticket per receipt converts delivery recovery into duplication.

Choose a contract-appropriate key and retain operation results. A repeated event for a fictional run should find its existing ticket rather than create another. Integration logic implements this protection.

Test identical payloads twice, incomplete data and unavailable destinations. Check receiver outcomes and error queues. Do not assume a particular Tigy retry policy without verifying its current contract; safe repeat handling remains necessary.

Turn data into a request someone can handle

Select fields guiding follow-up: reason, authorized contact, attempted action, result and unresolved task. Distinguish caller requests from system confirmation. “Requested rescheduling” must not become “rescheduled” just because the call ended.

Assign recipients and responsibility before enabling delivery. Unowned notification channels add visibility without guaranteeing service. Define failed-delivery review and missing-request discovery.

During the pilot, track the conversation, arrival of the notification, record creation and staff follow-up. The integration team must prepare a reachable address, agree on the data format and test the full path. Agree on access protection before using real information.

Define the outcome to be delivered

Post-call webhooks connect conversational outcomes to a system continuing service. Before choosing fields, define the purpose: create a task, record interest, update a report or notify staff. Each requires different information. Sending everything available without a defined consumer increases exposure and complicates interpretation.

In agent settings, enter the connection address supplied by the integration team, the required sending method and the available information you want to send. The notification is sent when the call ends. Check the panel’s current options rather than copying fields from an old example. Agree on the format with the destination system owner.

Separate collected facts from service conclusions. Expressing interest does not establish a confirmed sale. Recording a request does not establish resolution. Choose field names preserving those distinctions and document meaning for the receiver. An undefined “success” status can produce incorrect commercial automation.

Consider a fictional business recording callback requests. Minimum payload may contain conversation reference, approved contact details and reported interest. The destination needs to know whether the customer agreed to the next step. A complete transcript may be unnecessary for task creation; select what the process actually uses.

Define missing-field handling too. Someone can end the call before supplying email or decline contact. Receivers should neither invent values nor interpret absence as authorization. The contract should permit incomplete requests or avoid task creation under operational rules.

Make the receiver recognize repeated delivery

Receivers should handle repeated notifications without repeating unnecessary effects. Tigy documentation recommends idempotent processing. Receiving the same event twice should not create two contacts or tasks when both represent one call outcome. Do not rely on assumed single delivery to protect operations.

Choose an association key appropriate to the available contract. A stable conversation reference can distinguish repetition from new contact. If the same customer calls again, that may be a new event with another intention. Using only phone or email as a key can erase legitimate requests or mix outcomes from separate calls.

Validate format, method and authentication before processing. Event fields do not replace authorization rules in the destination. Company or customer identifiers need association with the service's authorized context, preventing received values from freely selecting access to another data population.

Plan the distinction between acceptance and completion at the receiver. It may acknowledge receipt and process later, but needs a way to investigate pending work. A success code does not establish final commercial action where the contract separates stages. Reports should show receipt, processing and outcome according to integration design.

Ask the integration team to test repeated notifications and simultaneous submissions in a test environment. Check how many records were created. Then send a new request from the same customer and verify it was not discarded. The goal is to distinguish a repeated request from a legitimate new contact, rather than merely checking that the connection responded.

Select data for purpose and access

Selecting a few useful fields improves maintenance and review. If staff need only contact reason and callback details, do not send whole recordings by default. An owner should approve what reaches the destination and who can access it. Webhooks can distribute data to systems with permissions different from the source platform.

Review free text such as summaries and transcripts. They may contain details not anticipated by field schemas. Do not assume a small payload is nonsensitive because it has only one text property. That property's content matters. Maintain access and retention rules consistent with company-defined use.

Do not put credentials in business payloads or copy them into public examples. Agree on receiver protection with its responsible team and limit debugging records to necessary information. Logs support investigation but can replicate content too. Staff should know where to find evidence without exposing secrets or copying complete records into inappropriate channels.

If receivers trigger communication, verify that events contain sufficient intention and conditions. General interest does not automatically authorize a message sequence. Processes should respect the next step agreed during conversation. Test someone declining follow-up to confirm that the same action used for consent is not created.

Investigate the whole delivery chain

When a task does not appear, check in order: did the call end, was the notification sent, did the destination receive the information and was the record created? A correct agent response does not prove delivery, and a working connection does not prove task creation. Ask the owner of the failed step for help before changing the information sent or the instructions.

Maintain a test call with a known outcome and inspect received fields. Check a customer correction and missing information. Then test authentication rejection and incompatible formats at the receiver without real data. Evidence should show how staff identify failure and resume requests under approved procedures.

Repeat the complete trial after field or destination changes. Apparently editorial changes can alter how receivers interpret status. Readiness means faithful information delivery and correct next steps, with repetition and pending work handled.

Assign ownership for both delivery and business processing. Otherwise each team can report its own stage as successful while the customer request remains unresolved between systems. A shared outcome definition closes that gap and makes webhook monitoring useful to actual service.