Connectors overview

Spatial assets become more valuable when they work with the applications your teams already use — geospatial platforms, rendering services, quality analysis tools, and publishing catalogs. Connectors are how SDMA leverages those external applications and services to transform, enrich, and interoperate with your content — and how those systems reach back in, governed by SDMA.

A connector can submit a compute job that converts a CAD file into a reviewable 3D format and writes the result back as a derived file. It can call an inference service that classifies imagery and writes quality scores into the asset record. It can look up metadata from a database or CSV and apply it across hundreds of files in one operation. It can publish structured metadata to a geospatial catalog, a data lake, or a project management system every time an asset changes. It can do several of these things in one governed contract.

A domain expert or administrator defines this once — what transforms to run, how to assess file quality, what metadata to enrich from which sources, where to publish — and attaches those connectors to a template. From that point on, every asset created under that template gets the benefit automatically. Files are converted, metadata is enriched, quality is assessed, and external systems are updated as content arrives. The people uploading and working with assets do not need to know how any of this works. They see governed, enriched, publication-ready assets from the moment of ingestion.

Connectors work through configuration, not code. You declare what should happen, when, with what data, under what credentials, and SDMA handles execution, security, failure policy, and audit. Every invocation is tracked. Every result flows back through the asset record with provenance. Connectors are governed through an explicit authorization chain: a connector is created and approved at the library level, a template author requests and approves which connectors are permitted for that class of assets, and a project uses that template. A connector does nothing until it is explicitly approved at each level. This means the people who define integrations, the people who define asset standards, and the people who create projects each control their own part of the chain.

With connectors, you can:

How connectors work

SDMA provides a small set of integration primitives — REST, S3, Deadline Cloud, Lambda, EventBridge — that connect your assets with the outside world. Each primitive can produce new content and bring it into SDMA (derive), or send content outward to external systems (publish). For a simple, single action — push metadata to an API, look up values from a CSV, submit a compute job — use a single-step publisher or deriver. When you need more, compose those same primitives into multi-step workflows within a single trigger. The primitives are the same either way.

A connector is a governed composition of five surfaces:

Execution flow

When a resource event occurs (for example, an asset is created or a file upload completes):

Connector directions

Every connector declares a direction that describes which way content flows across the integration boundary: outward (publish), inward (derive), or both (integration connectors using the bidirectional direction).

Publishers

A publish connector sends content from SDMA to an external system. It runs when a lifecycle event matches a trigger — for example, when an asset is created or a file upload completes.

A publisher can be a single operation (one REST call, one S3 write, one EventBridge event) or a composed sequence of steps that together accomplish the publication. In a multi-step publisher, steps execute in order and share intermediate state through $temp.* variables. For example, a publisher might create a record in an external system, capture the returned ID, then use that ID to upload file content in a second step.

Each step type is a reusable primitive. The same rest step type that powers a simple single-step publisher also participates in multi-step compositions alongside s3PutObject, lambdaInvoke, eventBridgePutEvents, and deadlineJob steps.

Derivers

A derive connector brings new content, reference data, or capability into SDMA. Derivers fill one or more of three roles:

A single derive connector can fill multiple roles. A connector integrating with a geospatial platform might provide resources for project linking at authoring time and enrich file metadata from the platform’s catalog on upload. It can also submit compute jobs for spatial analysis — all through one governed contract.

Integration connectors

An integration connector combines publish and derive roles in a single governed contract. Set the direction to bidirectional when the external system has a deep relationship with SDMA that spans both directions.

Integration connectors are multi-step and potentially bidirectional. They can compose operations across both directions — deriving content inward and publishing content outward — in a single governed contract. For example, a connector integrating with an external CAD management system might:

One connector, one set of credentials, one failure policy, one governance boundary — multiple roles across both directions.

How directions compose in multi-step integrations

Directions describe which way content flows. Step types describe what each operation does. These are independent axes. A derive connector uses the same rest step type a publisher uses. The difference is that the deriver routes results back into the asset record through output routing, while the publisher sends content outward.

Multi-step triggers can combine operations that feel like both directions. A trigger might call an external API to create a job (outward), poll for completion (outward), fetch the results (inward), and write metadata back to the asset (inward). All of these run in one trigger and SDMA tracks them as one invocation. The connector’s declared direction describes the overall intent; the steps describe the mechanics.

When one connector’s output needs to feed another connector’s input, composition happens through the asset record. A derive connector that produces a derived file creates a lifecycle event. A publish connector with a trigger on derivationComplete picks up that event and publishes the result. The two connectors do not reference each other — they compose through what they produce and consume in the asset record.

Supported connector types

A connector’s type identifies the external system it connects to. Each type is a multi-purpose primitive — the same type can publish content outward, derive metadata inward, expose resources for discovery, and participate as a step in multi-step workflows. The type determines the protocol and authentication model; the direction, triggers, and configuration determine what the connector does with it.

AWS Deadline Cloud

Step type: deadlineJob

Roles: content transformation, derived file production, metadata derivation from job output.

Submits batch processing jobs to AWS Deadline Cloud using Open Job Description templates. Jobs run on managed compute with access to GPUs, large local disks, and the third-party or licensed software your workflows depend on. Examples include CAD converters, point cloud processors, rendering engines, geospatial analysis tools, and AI/ML inference models. Format conversion, 3D rendering, spatial tiling, quality analysis, metadata extraction, and custom processing pipelines all run asynchronously at whatever scale Deadline Cloud provides. Results come back as derived files and metadata attributes on the asset, with full provenance linking the output to the job that produced it.

Deadline Cloud is the compute platform of choice for connector-driven transformation work. SDMA stores Open Job Description templates as governed assets. The combination of these templates with SDMA’s correlation and output routing means compute jobs are auditable, repeatable, and governed through the same template chain as every other connector.

For configuration details, see Create and transform content with AWS Deadline Cloud.

REST API

Step type: rest

Roles: publish metadata to external APIs, derive metadata from external APIs, expose external resources for discovery and linking, content production through API calls, multi-step orchestration.

The most versatile connector type. A REST connector can call any HTTP endpoint — external project management systems, geospatial platforms, inference services, catalog APIs, or any system with a REST interface. It supports all HTTP methods (GET, POST, PUT, PATCH, DELETE), session initialization for stateful protocols, SIGv4 signing for AWS service endpoints, and binary file upload.

As a publisher, it sends asset metadata to external systems. As a deriver, it calls external APIs and writes results back as metadata or derived files. As a resource provider, it exposes external resources for discovery and linking in the Spatial Data Portal. As a step in a multi-step trigger, it composes with other step types. A single REST connector can fill several of these roles in one governed contract.

For configuration details, see Working with REST APIs.

Amazon S3

Step types: s3PutObject, s3DeleteObject

Roles: publish structured metadata to S3, derive metadata from S3 files (CSV, JSON), expose S3-hosted reference data for resource provision.

An S3 connector can write structured JSON metadata to a bucket on asset events (publish role). It can read a CSV or JSON file from S3 and match records to SDMA files for bulk metadata enrichment (lookup role through s3Lookup). It can also serve values from an S3-hosted file as selectable options during template authoring (resource provision role).

For configuration details, see Amazon S3 connector. For the lookup role, see Metadata lookup and enrichment.

Amazon DynamoDB

Step type: n/a (used through the lookup-derivation model)

Roles: derive metadata from DynamoDB tables, expose DynamoDB-hosted reference data for resource provision.

A DynamoDB connector performs single-record lookups by partition key and writes the result as metadata attributes on matched files or assets (lookup role via dynamodbLookup). It can also serve values from a DynamoDB table as selectable options during template authoring (resource provision role). DynamoDB connectors are well suited for per-file enrichment where each file maps to a single record in an external table.

For configuration details, see Metadata lookup and enrichment.

AWS Lambda

Step type: lambdaInvoke

Roles: content production, custom processing, publish via code.

A Lambda connector invokes a function with resource metadata as the payload. Use this type when the integration requires custom code — transformations, validations, or processing logic that cannot be expressed through the declarative configuration of other step types. Lambda connectors can also route results back into the asset record through output routing, making them content producers as well as publishers.

For configuration details, see AWS Lambda connector.

Amazon EventBridge

Step type: eventBridgePutEvents

Roles: publish events to downstream consumers.

An EventBridge connector publishes events to a custom event bus when asset lifecycle events occur. Use this type to fan out resource events to multiple downstream consumers through EventBridge rules — for example, notifying external systems, triggering workflows in other AWS accounts, or feeding event-driven architectures.

For configuration details, see Amazon EventBridge connector.

STAC API

Step type: rest (specialized)

Roles: publish asset metadata as STAC Items to geoportal APIs.

A STAC connector maps SDMA assets to the STAC Item specification — geometry, bounding box, temporal properties, and per-file asset entries — and publishes them to a STAC-compliant geoportal API. This is a specialized application of the REST connector type, purpose-built for geospatial catalog interoperability.

For configuration details, see Publishing to STAC with the REST API connector.

Composable step types

Each connector type is also a reusable step type. Step types are composable — a single trigger can combine steps of different types to build multi-step workflows. For example, a trigger can write metadata to Amazon S3, then invoke a Lambda function to post-process it, and finally publish an event to EventBridge:

"triggers": [{
  "resources": ["asset"],
  "events": ["create"],
  "steps": [
    {
      "stepType": "s3PutObject",
      "s3Config": { "objectKey": "raw/${asset.assetId}.json" }
    },
    {
      "stepType": "lambdaInvoke",
      "lambdaConfig": { "functionArn": "arn:aws:lambda:us-west-2:123456789012:function:post-process" }
    },
    {
      "stepType": "eventBridgePutEvents",
      "eventBridgeConfig": { "eventBusArn": "arn:aws:events:us-west-2:123456789012:event-bus/my-bus", "source": "sdma", "detailType": "AssetPublished" }
    }
  ]
}]

The deadlineJob step type can also participate in multi-step triggers, enabling workflows that combine synchronous steps (REST calls, S3 writes) with asynchronous compute jobs.

This composability means you do not need a separate connector for each destination. A single connector can orchestrate a complete workflow by combining different step types in a single trigger.

Connectors, templates, and projects

SDMA uses a three-level relationship between connectors, asset templates, and projects to control which connectors can run and on which resources.

How the relationship works

This means:

Limiting blast radius

This three-level model limits the blast radius of any single connector: