Consuming Events

Everything the corridor observes reaches you as a GraphQL subscription on the Hub's single /graphql endpoint, over WebSocket or SSE. You can subscribe to individual topics — each of the topics in the Event Catalog has its own subscription field — or use the combined events(filter) stream when one connection should carry several event types. Start with the combined stream; switch to per-topic subscriptions when different consumers own different concerns.

Subscribe to clearance decisions

A typical integrator use case is reacting to watchlist clearance — green for allowed, red for denied. Using any GraphQL client with subscription support (for example graphql-ws in Node.js):

subscription {
  identificationClearanceGreen {
    correlationId
    unitId
    timestamp
    member { id name watchlist }
  }
}

Subscribe to identificationClearanceRed the same way to drive officer alerts or deny-side logic. Field names and payload shapes for every topic are discoverable through GraphQL introspection on the endpoint itself.

One stream, filtered

The combined subscription accepts an event-type filter, so a single connection can carry exactly the subset you care about:

subscription {
  events(filter: { types: [IDENTIFICATION_MATCH, ZONE_PERSON_ENTERED] }) {
    type
    unitId
    timestamp
    payload
  }
}

Reading history

The same endpoint answers queries over persisted events — by event type, time range, unit ID, correlation ID, and source system, paginated in chronological order. Remember that retention is short and configurable (see Event Storage & Retention); the event store is a rolling operational window, not a long-term archive. If you need long-term records, consume the live stream and persist events in your own system.