Consuming Events
Everything the corridor observes reaches you as a GraphQL subscription on the Hub's single /graphql endpoint (http://<host>:8090/corridor-foundation/graphql), over WebSocket or SSE. You can use the aggregate corridorEvents stream when one connection should carry every clearance decision and event, or subscribe to individual topics — each of the topics in the Event Catalog has its own subscription field. Start with the aggregate 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 aggregate subscription accepts an event-type filter, so a single connection can carry exactly the subset you care about:
subscription {
corridorEvents(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.
Raw Face Matcher data
If you need the biometric detail behind an event — face templates, detection metadata, the full identification history — that is Face Matcher's domain, not the corridor's: see RabbitMQ notifications and the Face Matcher GraphQL API.