TL;DR

Plan a SkyLight Chat integration across supported messaging channels, webhooks, contacts, knowledge sources, security, retries, and human handoff.

Start with supported operations, not assumptions

Channel providers expose different identifiers, template rules, media limits, delivery states, and permissions. First list the operations your workflow needs, then check the current SkyLight developer documentation for channel support, authentication, schemas, rate limits, and plan requirements.

1. Build from the documented API contract

Use only endpoint paths and request fields shown in the current documentation for your account. Keep provider-specific message IDs, normalize delivery states in your application, and test text, templates, media, replies, and failures separately for every enabled channel.

2. Make webhook processing reliable

Subscribe only to documented events. Store event IDs, acknowledge quickly, process asynchronously, make handlers idempotent, and tolerate retries or out-of-order delivery. Reconcile important contact or campaign states periodically instead of assuming a webhook alone creates perfect synchronization.

3. Treat knowledge sources as governed content

Connect knowledge sources using the methods available in your account. Assign an owner, record the source and update date, remove obsolete material, test citations, and route uncertain answers to a person. Grounding can reduce inconsistency, but it cannot guarantee a correct answer.

4. Verify security against current documentation

Follow the documented webhook verification method for your configuration; do not invent a signature header or algorithm. Keep secrets outside source control, compare signatures safely when signing is supported, reject stale requests, rotate credentials, restrict permissions, and log verification failures without recording message content.

5. Add observability without copying message content everywhere

  • Use correlation, provider-message, contact, event, and attempt IDs appropriate to the documented schema.
  • Record status transitions, latency, retries, rate limits, and failure codes with sensitive fields redacted.
  • Alert on sustained delivery failures, verification failures, queue age, duplicate processing, and handoff errors.
  • Define retention and access for operational logs separately from conversation retention.

6. Release checklist

  • Test in a sandbox or controlled account before using production recipients.
  • Verify authentication, least privilege, secret rotation, timeouts, retries, idempotency, and rate-limit backoff.
  • Test opt-in, opt-out, templates, quiet hours, identity matching, media, exports, and deletion.
  • Document the owner, rollback switch, support route, data flow, subprocessors, and contract limits.