A connector in an afternoon
The hard part of connecting an operator to a new system is everything around the HTTP calls: auth, retries, idempotency, audit, and policy. This note describes the intended Connector SDK boundary. The SDK is not a public self-service package today, and each managed connector still requires review and verification.
Ask anyone who has built integrations for a living and they will tell you the same thing: the API client is the easy fifth of the work. Fetching an order from Magento, updating a conversation in Kustomer, writing a setpoint over BACnet — each of these is an afternoon of reading documentation and mapping fields. What consumes the following month is the scaffolding nobody budgets for: token refresh, retry discipline, deduplication, rate limits, the audit story, and the uncomfortable question of what happens when your integration misbehaves against a production system.
That month is also where safety erodes. Every integration that reimplements scaffolding does it differently. The intended SDK boundary reduces that variation by centralizing common controls, while connector-specific semantics, credentials, and recovery behavior still require review.
Declare, don’t implement
A connector on Fibric is a declaration, not a framework exercise. You call defineConnector and hand it three things: an identity, an auth scheme, and a set of tools. Each tool declares what it senses or what it does — its inputs, its outputs, the entity it touches. The auth block declares how the target system grants access, and the platform handles acquisition, refresh, and storage from there. There is no base class to extend, no lifecycle hooks to get subtly wrong, no place where the kernel’s machinery is exposed for reimplementation. You describe the system; the platform operates it.
- The connector’s identity and auth declaration
- Tools: what each senses or does, typed in and out
- The mapping from the system’s shape to entities
- Common policy-gate interfaces for acting tools
- Idempotency and single-flight controls within the governed runtime
- Execution records, retry policy, auth handling, envelope normalization
The intended consequence is that managed connectors expose acting tools only through reviewed, policy-gated capabilities. That remains a reference contract until public SDK packaging, conformance tests, credential boundaries, and connector certification are available. External systems may still have independent write paths.
Why coercion beats convention
A catalog is only as trustworthy as its weakest active integration. Today, five listings support live BearScope paths and the remaining listings are managed early access. There is no public third-party publishing path, and BACnet or other physical connectors require deployment-specific safety review rather than inheriting a universal assurance from a manifest.
The afternoon, honestly accounted
Can the mapping draft fit in an afternoon? Sometimes, for a well-documented SaaS API. Production readiness still includes auth review, failure handling, rate limits, semantic mapping, recovery tests, observability, and security review. Hardware protocols require additional commissioning and independent safety controls. The title describes a design goal, not a delivery promise.
The catalog currently has 48 listings: 5 live in BearScope and 43 available through managed early access. Public publishing, sales, and a contractual marketplace fee are not available today.
Keep reading: Capability, then connector · The Kustomer connector