Four surfaces
API, webhook, widget SDK and workflow are different contracts
Start with one business transaction: create a CRM contact, write back ticket status or archive a message with evidence. Name sender, receiver, trigger, fields, latency, failure path and system of record.
The phrase API-ready is insufficient. Require base URL, version, authentication, scopes, endpoints, event catalogue, sample payloads, pagination, rate limits, changelog, deprecation notice and support model for your exact case.
| Surface | Typical purpose | Not automatically included |
|---|---|---|
| Product API | read or write records and invoke actions | real-time events or user interface |
| Webhook | notify an endpoint about selected events | arbitrary queries, full history or exactly-once delivery |
| Widget SDK | control browser behaviour, identity, presentation or tracking | server-side agent, export or compliance API |
| Power Platform | orchestrate Teams, connectors and target systems in a flow | a general native product API or ready connector for every CRM |
Evidence matrix
What official sources actually establish
| Product | Documented | Boundary before purchase |
|---|---|---|
| WebChat | channel keyword, Teams connector, Power Automate and optional target systems | no general product API, webhook surface or widget SDK established in reviewed public sources |
| Chatwoot | Application, Client and Platform APIs; selectable account webhooks with HMAC signatures | test token permissions, API class, Cloud/self-hosted boundary and delivery semantics by release |
| Tidio | OpenAPI, Widget SDK and signed webhooks with topics, version and webhook ID | webhooks documented for Plus/Premium and owner/admin; API-originated changes do not emit webhooks |
| LiveChat | Agent and Customer Chat APIs, Web/RTM, registered webhooks and granular scopes | accept app, OAuth/PAT, roles, filters, plan and version in the target account |
Operations
At-least-once requires idempotency and reconciliation
Tidio explicitly documents possible duplicates, no guaranteed order, a unique webhook ID and that OpenAPI changes do not trigger webhooks. LiveChat describes a short acknowledgement window and limited retries. Chatwoot documents signature, timestamp and delivery headers, while your proof of concept must establish the retry and ordering behaviour of the release you will run.
Green HTTP codes are not an audit. Measure received, verified, deduplicated, processed, failed and reconciled events separately and correlate them with a business object ID.
- Acknowledge webhook requests quickly with 2xx, then process the payload asynchronously through a queue.
- Verify signatures over the unchanged raw body, timestamp and accepted time window; rotate secrets deliberately.
- Use delivery, webhook or event ID for deduplication and make every side effect safe to retry.
- Order by business event time and stable identifier; arrival order must not drive state transitions.
- Quarantine dead-letter cases, alert an owner and provide controlled replay.
- Reconcile regularly through an API because events may be delayed, duplicated, filtered or never emitted.
- Version payload schemas and consumers; tolerate unknown fields, reject missing required fields and monitor deprecations.
Security and privacy
Minimise tokens, payloads and write-back rights
A valid webhook signature proves origin and integrity under the shared secret. It does not prove the sender was authorised for the business action or that your receiver may execute it.
For a Teams and Power Platform route, include flow owner, connections, DLP policy, environments, connector licensing and the visitor return path in the same control model.
- Separate test and production, outgoing webhook secrets, API tokens and interactive user identities.
- Grant only required read/write scopes; global chat, contact or admin access needs explicit justification.
- Map names, email, phone, message text, attachments, IP/browser data and internal notes in the data-flow register.
- Encrypt queue, logs, replay store and secrets; mask personal content in telemetry.
- Protect write-backs with state validation, allowlists, approval for risky actions and an audit log.
- Define retention, access and deletion for event copies, error queues, exports and backups too.
Acceptance
Eight tests before choosing the integration
- 01
Freeze the contract
Record use case, system of record, API version, endpoints, events, fields and expected latency.
- 02
Deny access
Expired, wrong and under-scoped tokens plus a foreign account must fail safely.
- 03
Verify signatures
A changed body, old timestamp, wrong secret and replay must trigger no action.
- 04
Send duplicates
Deliver the same event repeatedly and concurrently; it may take business effect only once.
- 05
Break ordering
Handle update before create, delayed close and simultaneous messages deterministically.
- 06
Force failures
Exercise timeout, 500, queue stop, target failure and rate limit with retry, alert and recovery.
- 07
Reconcile a gap
Lose a webhook or create an API-originated change, then find the record through reconciliation.
- 08
Prove exit
Rotate secret, revoke app, remove webhook, export delta and delete stored event copies on schedule.