Connector Registry Domain

Overview#

A development team is building a new OSINT connector for a specialist dark web intelligence provider. They need to know what the platform expects: what capabilities to declare, what configuration schema to use, what the sample output format should look like. Rather than asking an internal team, they consult the SDK manifest from the Connector Registry. Everything they need is there, metadata contracts, development quickstart guides, and example configurations for each category of connector already registered.

The Connector Registry is the central catalogue that makes the platform's connector ecosystem discoverable, manageable, and extensible.

Key Features#

Connector registration with category classification (OSINT, financial, social, dark web, telemetry, custom).
Status tracking across five states: registered, active, degraded, error, disabled.
Heartbeat recording for health monitoring with latency tracking.
SDK manifest providing development quickstart guides and metadata contracts.
Registry summary metrics for total, active, degraded, error, and disabled connectors.
Connector definition schema including capabilities, config, and sample output.
Deployment target management for connector lifecycle.
Connector disable with reason tracking for operational audit.

Use Cases#

Third-party connector developers consult the SDK manifest when building new integrations, accessing capability declaration schemas and metadata contracts without needing to work through internal documentation channels.

Platform administrators monitor connector fleet health through heartbeat tracking and status summaries, identifying degraded or failed connectors before they affect downstream investigation workflows that depend on their data.

Integration architects browse the registry catalog to understand which capabilities are already covered before commissioning new connector development, avoiding duplication across the platform's 153 third-party integrations.

Operations teams manage the connector lifecycle from registration through disablement, maintaining a reason-tracked audit trail for every disable operation to support post-incident review.

Integration#

Integrates with connector execution, data source management, and OSINT provider systems for unified connector lifecycle management.

Open Standards#

OASIS STIX 2.1: Each registered connector must declare STIX 2.1 as its primary output contract when producing cyber-threat intelligence objects, and connector output is validated against the STIX 2.1 schema in Phase 1 of the two-phase extraction architecture.
GraphQL (June 2018 specification): All registry operations, listing connectors, recording heartbeats, retrieving the SDK manifest, and managing lifecycle, are exposed exclusively through a typed GraphQL API implemented with Strawberry.
OAuth 2.0 (RFC 6749) scopes: Access to connector management and heartbeat mutations is gated on named OAuth 2.0 scopes (connectors:manage, connector:heartbeat), enforced per request before any data is read or written.
JSON Schema (draft-07 / 2020-12): Connector definitions carry config_schema and secrets_schema fields that are JSON Schema documents; the SDK validates user-supplied configuration payloads against these schemas at registration time.
OASIS CAP 1.2 (Common Alerting Protocol): CAP 1.2 is a named, first-class output standard that connectors ingesting emergency-alert feeds may declare, ensuring their extracted payloads conform to the OASIS emergency-alerting specification.
NIEM (National Information Exchange Model): Connectors handling law-enforcement or government data-sharing payloads may declare NIEM as their output standard, aligning extracted data with the US national information-exchange framework.
ITU-R M.1371 (AIS, Automatic Identification System): Maritime-domain connectors may declare AIS as their primary output contract, indicating that extracted vessel-position messages conform to the ITU-R M.1371 Automatic Identification System standard.
STANAG 4607 (NATO GMTI): Connectors producing ground-moving-target-indicator data may declare STANAG 4607 compliance, ensuring outputs conform to the NATO standardisation agreement for GMTI sensor feeds.

Last Reviewed: 2026-02-05 Last Updated: 2026-04-14