Skip to main content
This page provides an overview of all Speckle connectors and links to their detailed documentation. Each connector follows the same fundamental data model but has connector-specific extensions and behaviors. Here you’ll learn the purpose of connector-specific object types, how they relate to the core schema, and see a conceptual example of how domain objects map to Speckle’s structure.

Purpose of Connector-Specific Object Types

Connector-specific object types (like RevitObject, ArchicadObject, TeklaObject) extend the base DataObject with additional fields that preserve native semantics from the source application. These extensions enable:
  • Semantic preservation: Native concepts (like Revit’s “Family” and “Type”) are preserved as first-class fields
  • Source mapping: Objects can be mapped back to their source application elements
  • Domain-specific data: Connector-specific properties (like Civil3D’s baseCurves) are accessible directly
Important: Despite these extensions, all connector-specific objects follow the same core schema rules:
  • They are DataObjects with properties and displayValue
  • They participate in the same Collection hierarchy
  • They are referenced by Proxies using applicationId
  • Their geometry is stored in displayValue as interoperable primitives
Conceptual example: A beam in Tekla is both:
  • A TeklaObject (connector-specific): Has TeklaObject-specific fields like profile, material, class
  • A Speckle DataObject (core schema): Has properties, displayValue, applicationId, follows the same structure as all DataObjects
The connector-specific fields preserve Tekla semantics, while the core DataObject structure ensures interoperability. A receiver that doesn’t understand Tekla can still render the geometry from displayValue and access basic properties.

Connectors

Connector Comparison

ConnectorHierarchy PatternObject TypeProxiesInfo Fields
RevitFile → Level → Category → TypeRevitObjectRenderMaterial, Level, GroupReference Point Transform, Views
RhinoFile → Layer → SublayerGeometry, InstanceRenderMaterial, Color, Group, DefinitionViews
AutoCADFile → LayerGeometry, InstanceRenderMaterial, Color, Group, Definition-
Civil 3DFile → LayerCivil3dObject, Geometry, InstanceRenderMaterial, Color, Group, Definition, PropertySetDefinition-
NavisworksFile (flat) or Selection TreeNavisworksObjectRenderMaterial-
ArchiCADFile → Floor → TypeArchicadObjectRenderMaterial-
TeklaFile → TypeTeklaObjectRenderMaterial-
ETABSFile → Level → Design OrientationEtabsObjectSection, MaterialAnalysis Results
IFCProject → Site → Building → StoreyDataObjectRenderMaterial, Level-

Common Patterns

BIM Connectors (Revit, ArchiCAD, Tekla, ETABS)

  • Use DataObject extensions (RevitObject, ArchicadObject, etc.)
  • Organize by spatial hierarchy (Levels/Floors)
  • Include rich properties (parameters, quantities, classifications)
  • Use Level proxies for floor associations

CAD Connectors (Rhino, AutoCAD, Civil 3D)

  • Support standalone geometry objects
  • Organize by layers
  • Use Instance/Definition pattern for blocks/components
  • Include Color proxies for visual styling

Special Cases

  • Navisworks: Can flatten hierarchy or preserve selection tree
  • IFC: Follows IFC spatial structure (Project → Site → Building → Storey)
  • ETABS: Includes analysis results in Info section

Connector Page Structure

Each connector page follows this structure:
  1. Description - What the connector exports
  2. Hierarchy - How collections are organized
  3. Object Extensions - Connector-specific fields on DataObject
  4. Proxies - Which proxy types are used
  5. Info Fields - Model-level metadata
  6. Example - Canonical object example
  7. Invariants - Connector-specific rules and caveats

Conceptual Capability

After reading this page, you understand how connector-specific object types extend the core schema while preserving native semantics. You recognize that all connectors follow the same fundamental structure (Collections, DataObjects, Proxies, Info) but add connector-specific fields to preserve domain concepts. You can see how a single domain object (like a beam) is both connector-specific (preserving native semantics) and a core Speckle DataObject (ensuring interoperability). You’re ready to explore specific connector pages for detailed behaviors.

Using This Documentation

  1. Start with core concepts - Understand Concepts, Object Schema, Proxy Schema first
  2. Review connector pages - Understand connector-specific behaviors
No! Read only the connectors you’re working with. The core concepts apply to all connectors, and connector pages are reference material for when you need connector-specific details.
New connectors are added regularly. If you’re working with an unlisted connector, it still follows the same fundamental data model. Check the connector’s release notes or contact the Speckle team for connector-specific documentation.