OGC API Features and ArcGIS feature services differ
OGC API Features defines a modular open interface for discovering and querying feature data, while an ArcGIS Feature Service exposes an ArcGIS service's layers, tables, capabilities, queries, and optional edits. Teams should select the contract they can govern and test, then make any adapter explicit.
Editorial figure by Civic Permit Review. Source context: OGC API Features and Esri Feature Service references.
Select and prove the feature-service contract
| Decision | Evidence to retain | Boundary to preserve |
|---|---|---|
| Required operations | Discovery, collection or layer metadata, filters, identifiers, paging, CRS, fields, writes, attachments, and history | A map display does not prove the required API behavior |
| Contract choice | OGC conformance parts or ArcGIS service version and advertised capabilities | A product label does not establish every optional capability |
| Data meaning | Field definition, identifier authority, geometry type, units, code lists, null rules, currency, and effective date | Syntactic compatibility does not establish semantic equivalence |
| Adapter | Source and target paths, transformation rule, loss handling, pagination, errors, version, tests, owner, and approval | An adapter cannot create facts absent from the source |
| Operational proof | Exact endpoint, authentication, representative queries, limits, update behavior, error cases, and retained results | Documentation does not prove a local service works or stays current |
Choose from the governed integration job
The direct answer is to target OGC API Features when the integration needs a standards-defined, implementation-neutral feature-access contract; target an ArcGIS Feature Service when the participating service and required operations are governed through the ArcGIS REST model; and use a documented adapter when both contracts must participate. Start with the reader decision: which parcels, zones, permits, inspections, or other features must be discovered, queried, filtered, paged, transformed, and possibly edited, by whom and for what authoritative use. [1] [2]
Do not select from the phrase REST API alone. Record the exact endpoint, publisher, dataset authority, collection or layer, fields, stable identifiers, geometry, coordinate reference systems, filters, pagination, record limits, authentication, update cadence, error model, write needs, version, and expected consumers. A public map, a successful sample request, or a vendor platform name does not establish that the full decision contract is available.
Read OGC conformance by supported part
OGC's official page describes API Features as modular web APIs for discovery and query of feature data. Its visible standard family separates Core from additional coordinate-reference-system and filtering capabilities, with CQL2 supporting the filtering model. An implementation claim therefore needs the supported conformance classes, operations, content types, collections, query parameters, paging behavior, coordinate handling, and test results; support for one part should not be expanded into support for every optional part. [1]
For a permitting integration, test the exact collection and representative records rather than an abstract standards claim. Include a known identifier, a bounding-box or other supported spatial query, a business filter, pagination beyond one response, a non-default coordinate system when required, missing and null attributes, a corrected record, and an invalid request. Retain the request, response, headers, time, endpoint version, conformance declaration, and reconciliation to the authority record. [1]
Read ArcGIS capabilities from the service
Esri's official REST reference describes a Feature Service resource containing layers and tables and exposing service metadata. The service response can advertise supported query and editing behavior, maximum record count, output spatial reference, synchronization, extraction, and other version-dependent properties. Treat that metadata as the contract presented by the exact service at the time of review, then confirm each required operation against the layer or table that owns the records. [2]
Separate read access from edit authority. A service that answers a query may not allow adds, updates, deletes, attachments, synchronization, or branch-version workflows, and an advertised capability may still be constrained by credentials, ownership, service configuration, field rules, or record limits. Preserve the user or application identity, operation, before state, submitted change, server result, edit moment, authoritative review, and any rollback or correction. [2]
Govern an adapter as its own interface
When an OGC-facing consumer depends on an ArcGIS service, document the adapter's source operation, target operation, identifier rule, field and code mapping, geometry and CRS transformation, filter translation, sort and page behavior, authentication boundary, write policy, unsupported capability, error translation, caching, freshness, version, owner, and test fixture. Mark every dropped, defaulted, combined, inferred, or nonrepresentable value. Keep the source response so a reviewer can distinguish authority data from adapter output. [1] [2]
Civic Permit Review freshly reviewed the exact OGC and Esri pages on October 12, 2026; both returned HTTP 200 in the strict source gate. The OGC page identifies its modular standards family, and the Esri page documents the Feature Service resource and advertised capabilities. The closest existing canonical tests whether one OGC parcel endpoint is operationally testable; this comparison instead chooses between an open-standard contract, a platform service, and a governed adapter. Neither source proves any local endpoint, data authority, configuration, portability, or production outcome. [1] [2]
Limitations and unknowns
- No particular civic endpoint's OGC conformance classes, ArcGIS version, capabilities, credentials, rate limits, record limits, paging, CRS behavior, edits, attachments, synchronization, or availability were tested.
- Dataset authority, parcel and zone identity, field semantics, geometry accuracy, effective dates, correction history, refresh timing, and legal use remain unverified.
- No OGC-to-ArcGIS field mapping, filter translation, error translation, loss analysis, performance result, portability result, or production adapter was independently evaluated.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Civic Permit Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.