Overview
Build webhook-assisted data synchronization only within Lucid's documented data-connector model. Do not claim generic Lucid document, shape, or collaboration event webhooks.
Prerequisites
- A justified Lucid data connector and supported source-system webhook contract
- Stable source record/event identifiers and reconciliation API
- Endpoint, identity, retention, observability, replay, and rollback owners
Tool Discipline
Use Read, Glob, and Grep to inspect connector and handler code, WebFetch for current Lucid and source contracts, and Write or Edit only for local implementation, synthetic fixtures, and redacted receipts.
Current Contract
Lucid documents a webhook SDK in the context of data connectors. Exact interfaces come from the current SDK/docs. Delivery authentication, signing, event names, ordering, retry, and retention may be source-system responsibilities and must be verified there—not invented as universal Lucid guarantees.
Authentication
Authenticate each boundary independently: Lucid connector, webhook source, and upstream reconciliation API. Keep secrets server-side; validate the source's documented authenticity mechanism and never invent a LUCID_WEBHOOK_SECRET convention.
Instructions
- Prove the use case belongs to a data connector and identify the authoritative source system.
- Re-fetch Lucid webhook/connector docs and the source's official delivery contract; record unknown guarantees.
- Define event envelope validation, stable IDs, freshness/replay window, deduplication, ordering tolerance, and reconciliation.
- Make the receiver acknowledge quickly and enqueue bounded work; isolate poison events and apply backpressure.
- Treat webhook data as a change hint. Fetch/reconcile authoritative state before mutating connector data when the source contract permits.
- Test valid, invalid-auth, malformed, duplicate, reordered, delayed, missing-record, partial-sync, and replay scenarios with synthetic fixtures.
- Present registration, endpoint exposure, secrets, expected traffic, data mutations, and disable/rollback plan for approval.
- After approval, enable a bounded canary and record registration ID, counts, rejects, duplicates, lag, reconciliation, and rollback.
Approval Boundaries
Do not expose/register endpoints, create secrets, replay production events, mutate connector data, or enable delivery without approval.
Output
Return contract evidence, architecture, auth method, validation/dedup policy, tests, mutation preview, canary receipt, reconciliation, and rollback.
Error Handling
| Condition | Response |
|---|---|
| Request is for generic document events | Report that this pack has no verified contract; do not fabricate one. |
| Delivery authenticity is undocumented | Keep the endpoint disabled until the source contract is verified. |
| Duplicate or reordered events diverge state | Pause consumption and reconcile from the authoritative source. |
Example
surface=data-connector; source=approved-system; fixtures=8/8; duplicates=0; canary=not-approved; generic-document-events=unsupported
Resources
Next Steps
Enable only a reversible canary, then compare webhook-assisted state with a full authoritative reconciliation.