OpnIMG's outbound surface is deliberately partner-shaped. Clusters and validated observations are emitted through documented endpoints — signed webhooks, an OGC WFS 2.0 feed, a NIEM 6.0 JSON-LD feed, and an Esri Feature Service-compatible endpoint. The receiving partner reconciles each cluster against its own authoritative asset database and returns an opaque reference number. OpnIMG records the reference in an append-only audit ledger and never stores the partner's internal asset identifier.
POST /v1/clusters/{id}/resolve with opaque reference number callback.
QGIS, ArcMap, Esri Mobile consume directly from /v1/incidents/wfs.
EM-LOC JSON-LD feed at /v1/incidents/niem for federal interoperability.
FeatureServer/0/query semantics at /v1/incidents/esri.
The integration design is intentionally narrow: we deliver a clean, validated cluster feed and let the systems you already own decide what to do with it.
Cluster co-incident multi-observer observations under geometric, CV, and temporal agreement. Score each cluster against a composite confidence formula. Emit cone-intersection polygon, aggregated CV evidence, and thumbnails to the partner. Record the partner's opaque reference number in an append-only audit ledger. Translate the same cluster into multiple endpoint shapes.
Generate work orders or assign crews. Replace your OMS, ADMS, EMS, or 311 platform. Hold the authoritative asset record — partner systems remain the source of truth. Store the partner's internal asset identifier, asset type, or asset label. Surface architectural depth in public — that lives in NDA conversations.
Outbound endpoints respect partner scope: a partner only sees rows associated with the territories and tenants its credentials authorise, and audit-ledger queries are partner-scoped at the row level.
The same validated cluster is exposed through four endpoint families so each partner type can consume what fits its tooling. Delivery channel is selected per deployment; idempotency is configurable within a sixty-second default window.
Partner webhooks are configured per tenant with a delivery preference (api_only, webhook_only, or both) and a cluster scope (resolved_only or all_high_confidence). Signed and idempotent within a sixty-second window. Callback at POST /v1/clusters/{id}/resolve accepts an opaque reference number for the audit ledger.
GET /v1/incidents/wfs serves a Web Feature Service 2.0 feed that QGIS, ArcMap, and Esri Mobile consume natively. This is the path partners take when they want validated observations directly on a GIS analyst's map.
GET /v1/incidents/niem emits the same validated observation feed in NIEM 6.0 JSON-LD — the structured-data exchange shape FEMA and DHS expect for federal interoperability.
GET /v1/incidents/esri (catalog) and /v1/incidents/esri/0/query (FeatureServer/0/query semantics) make the feed available to ArcGIS Online and ArcGIS Pro out of the box, without a custom connector.
GET /v1/config/disaster-status — current FEMA disaster declaration state, exposed to capture clients for first-72-hour prioritisation.
GET /v1/config/satellite-carriers — current satellite carrier hints used by the PWA to choose the highest-probability sync path during the first window after impact.
The Reference-Number-Only Architecture is the contract between OpnIMG and the partner system. It is designed so that the surface-of-data we hold approximates only what is strictly necessary for downstream partner action — which materially reduces the CEII, PII, and GDPR exposure that an internal asset registry would have created.
Cluster identifier · cone-intersection polygon (WKT) · aggregated CV evidence · damage class & severity · contributor-tier breakdown · composite confidence score · active-event reference · thumbnails. PII-stripped before it leaves our pipeline.
The partner system resolves the cluster against its authoritative asset database and returns an opaque reference_number. OpnIMG records the reference number, the resolving partner, the timestamp, and optional confidence in the append-only cluster-partner-resolutions ledger.
We do not store partner_asset_id, partner_asset_type, or partner_asset_label. We do not centralise utility asset data. We do not approximate the CEII / NERC CIP-011 / CIP-014 protected surface.
Per-observation retention in the cluster-partner-resolutions ledger is thirteen months. A separate partner-resolution-aggregates table holds seven-year FEMA-style summaries without per-observation detail — sufficient for federal Public Assistance reporting structures, scoped to the minimum data necessary.
The list below describes families of systems we have prepared adapters for. The specific connectors activated for any deployment are scoped during initial discussions.
Mention of a vendor name above describes the system family our adapters target. It is not a claim of partnership, certification, or active production integration unless explicitly confirmed in a separate announcement.
We are actively interested in conversations with GIS platforms, OMS / ADMS vendors, EMS / EOC providers, 311 platforms, and systems integrators with deployments in tier-1 utilities, FEMA / state EM, and large municipalities.
The partner relationship is reciprocal: we deliver a clean validated cluster feed into your system, your system returns an opaque reference number that closes the loop. Your customers get richer ground truth without changing the platform they already trust for routing, dispatch, work orders, or citizen interaction. And the asset record stays inside the system that authoritatively owns it.
Endpoint family and authentication preference. Payload mapping into your native data model. Reference-number contract for closing the loop. CEII / PII / GDPR handling that complements your existing posture. Joint pilot scoping with a mutual customer where applicable. NDA-scoped architectural detail.
GIS platforms, OMS / ADMS, EMS / EOC, 311, systems integrators, and any partner adjacent to the operating systems we emit into. We do not publish email addresses.
