Skip to main content
A webhook connects a ContactShip event to a URL in your system. There is no single platform-wide webhook: choose the event timing and data you need.

​
Choose the event

​
What each webhook sends

Analyzed call

ContactShip sends: { "data": { "agent": {}, "organization": {}, "call": {}, "campaign": {}, "contact": {} } }, with conditional blocks.Delivery follows analysis and may wait for evaluations. Your receiver accepts the event with HTTP 2xx. Configure delivery and inspect attempts in Call webhooks. See the exact fields and examples.
ContactShip sends: call with direction and phone numbers, agent_id, organization_id, and contact when available.Your system responds: a JSON object with information the agent needs, such as balance or order status. The response is used during the conversation; it is not the final result. See the inbound-context contract.
Select INSERT, UPDATE, or DELETE: these describe conversations, not every individual message. Configure the URL and switch in Channel → Advanced.Capture a controlled event in your receiver to map that channel’s fields. Do not apply the data.call schema. To explicitly control the outgoing body, use an automation with Body template.
Choose the rule’s trigger and conditions. The action accepts URL, POST, PUT, or PATCH, headers, and Body template. An empty body sends the full event context.Define your own body using the variables you need. In Run History, inspect Trigger Payload and the action’s Output to verify available values and the result. See inbox automations.
Sends event: "follow_up_closed", threadId, agentId, closure reason, stages, timestamp, contact, and summary. Its body differs from voice webhooks and has no data envelope.It does not represent every manual inbox closure. See the closure fields and example and follow-up settings.
The out-of-hours webhook sends a POST when that channel rule applies. Configure it in Responses and verify a controlled message in your receiver.Routing notifications describe assignments and deadlines. The current screen does not expose a public webhook editor. Coordinate the contract with support using Conditions, notifications, and webhooks. Do not reuse another webhook’s parser or signature.

​
Test an integration

1

Separate receivers

Use different routes or workflows for voice, inbound context, and messages. Each can require a different body or response.
2

Trigger a controlled event

Test the actual scenario: call, message, closure, or conversation change. A sample JSON body is not proof of delivery.
3

Keep the body and response

Inspect data in your receiver. For voice, compare with Calls → Webhooks; for inbox rules, use Run History.
4

Verify the final action

Check the ticket, task, or update in your system. A successful HTTP response alone does not prove that action completed.
Retries, headers, and signatures depend on the webhook type. Call webhooks do not add the routing signature, and follow-up closure does not share their retry mechanism.

​
Frequently asked questions

Only if your receiver distinguishes the contracts. Separate routes simplify mapping and prevent treating a context request as a notification.
In your receiver logs or history. For calls, also use Calls → Webhooks. For automations, inspect Trigger Payload and Run History steps.
No. Its events describe conversations. Choose the new-message automation trigger for individual messages.

​
Continue with

Call webhook

Complete fields and examples.

Connect your system

From an API request to its result.