Anatomy of a connector: Kustomer
Kustomer supports live BearScope data paths. This article describes the intended governed read and write contract; duplicate suppression depends on stable identity, downstream behavior, and explicit handling when an external outcome is unknown.
A connector is where Fibric's promises meet someone else's API, and someone else's API does not care about your promises. It times out. It rate-limits. It returns a 500 after the write succeeded. The connector's job is to absorb all of that and present the kernel with two clean surfaces anyway: a stream of events it can trust, and a set of effects it can retry without fear.
Reads as governed events
Conversations, messages, status changes: each arrives, is normalized into the canonical envelope, stamped with tenancy and provenance, and only then becomes something an operator may reason about.
Writes with duplicate controls
For enabled write paths, notes or updates should use a stable key, policy checks, an execution record, and connector-specific reconciliation.
The inbound half: nothing raw reaches the operator
Kustomer produces a lot of shapes: webhook payloads, list endpoints, and nested conversation objects. On the supported BearScope path, covered reads are normalized with tenant and source context before they become governed CX records.
The normalization boundary reduces vendor-specific coupling for the covered fields and makes those records easier to trace. It does not mean every Kustomer object, event, or external system is normalized or that source data is inherently complete.
The outbound half: three effects, one discipline
On an enabled write path, the connector can expose bounded capabilities such as posting a note or changing selected fields. The deployment must verify policy, entity locking, key derivation, downstream permissions, and record coverage for each capability.
When a network timeout hides the response, the connector does not automatically know whether a note landed. A stable key helps only if Kustomer accepts it for that operation or the connector can reliably look up the prior effect. Otherwise the safe path is reconciliation or review, not blind retry.
Retries are safe only on paths whose downstream idempotency or reconciliation behavior is verified. Rate limits and timeouts remain correctness concerns when a response can hide a completed external write.
Status changes are effects too
It is tempting to treat a status change as lighter than a note. An enabled write path should apply the same scope, policy, record, and recovery review appropriate to its consequence. Current live support for a read connector should not be read as proof that every Kustomer write is enabled or routed through the generalized executor.
Why the anatomy repeats
A common connector vocabulary can make reviews repeatable across Kustomer, Magento, Amazon Connect, and managed reference listings such as BACnet. It does not make their failure semantics identical. Each connector must define provenance, permissions, duplicate controls, recovery, and evidence appropriate to its downstream system.
The shipping bar is therefore broader than a declaration: governed reads with correct scope, bounded writes, stable identity where possible, explicit ambiguous-outcome handling, security review, and deployment acceptance tests.
Keep reading: Swap the system, keep the operator · Idempotency is a kernel primitive