OGC API - Publish/Subscribe Workflow

OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. OpenAPI is used to define the reusable API building blocks with responses available in different representations, such as JSON and HTML.

The OGC API — Publish-Subscribe Workflow — Part 1: Core Standard defines building blocks that can be assembled to implement Publish-Subscribe workflows (discovery, topic structure, encoding) as part of OGC API Standards.

This Standard defines a discovery capability that contains a topic structure in support of binding to notifications for data access and retrieval.

This Standard also defines baseline message payloads which can contain summary descriptive information about a given notification for new data events (new granule, new model run, etc.).

Overview of OGC API - Publish/Subscribe Workflow

Advertising Pub/Sub brokers

An OGC API server can advertise an associated Pub/Sub server as part of their landing page as follows:

Example: MQTT broker

{
    "rel": "hub",
    "title": "Data notifications",
    "href": "mqtt://example.org:8883"
}
                    

Example: Kafka broker

{
    "rel": "hub",
    "title": "Data notifications",
    "href": "tcp://example.org:9092"
}
                    

AsyncAPI is the event driven equivalent of OpenAPI. To advertise AsyncAPI link from an OGC API landing page:

Example: AsyncAPI link

{
    "rel": "service-desc",
    "type": "application/asyncapi+json",
    "title": "AsyncAPI document",
    "href": "https://example.org/asyncapi?f=json"
}
                    

Implementing topic structures using OGC API endpoints

OGC API endpoints are a useful structure and hierarchy to publish notifications to a Pub/Sub broker or message bus.

Specific topic subscription examples (using MQTT syntax):

Description	Topic
Subscribe to updates to any collection	collections
Subscribe to updates for a specific collection	collections/collection123
Subscribe to updates for a specific collection item	collections/collection123/items/item456
Subscribe to updates for a specific process	processes/process123

Publishing a notification message using CloudEvents

Publishing CloudEvents can be implemented in a flexible manner depending on the workflow and infrastructure requirements, as exemplified below (note the use of the type element which follows the specification patterns).

Example CloudEvents message payload with a created inline feature

{
  "id": "6e1c7f9f-dd6c-48d9-bbc4-aef0625f1fb8",
  "specversion": "1.0",
  "type": "org.ogc.api.collection.item.create",
  "source": "https://example.org/api/collections/obs",
  "subject": "https://example.org/api/collections/obs/items/964",
  "time": "2025-08-27T12:36:33Z",
  "datacontenttype": "application/json",
  "data": {
    "type": "Feature",
    "id": "964",
    "geometry": {
      "type": "Point",
      "coordinates": [
        -122,
        49
      ]
    },
    "properties": {
      "stn_id": 604,
      "datetime": "2000-10-30T18:24:39Z",
      "value": 99.9
    },
    "links": [
      {
        "rel": "collection",
        "type": "application/json",
        "title": "Observations",
        "href": "https://example.org/api/collections/obs"
      }
    ]
  }
}
                    

Example CloudEvents message payload with a created feature by reference

{
  "id": "6e1c7f9f-dd6c-48d9-bbc4-aef0625f1fb8",
  "specversion": "1.0",
  "type": "org.ogc.api.collection.item.create",
  "source": "https://example.org/api/collections/obs",
  "subject": "https://example.org/api/collections/obs/items/964",
  "time": "2025-08-27T12:36:33Z",
  "datacontenttype": "application/json",
  "data": {
    "type": "application/geo+json",
    "rel": "item",
    "href": "https://example.org/api/collections/obs/items/964"
  }
}