Whitespace Platform Activity Queues
Version 3.1
An AsyncAPI description of the Whitespace Platform event surface, generated by API Evangelist from Whitespace's own published queue guides. Whitespace does NOT publish an AsyncAPI document and does not offer HTTP webhooks — its event mechanism is a per-client Microsoft Azure Service Bus queue. Every significant user action on the platform creates a JSON activity document (`RWActivity`, optionally `RWCustomActivity`, and `RWComment` where the integration requires chat). That document is placed on the client organisation's queue, time-stamped, and served in strict first-in-first-out order. The message carries no sensitive contract data: it carries the activity string, the document reference and the message id, which the consumer then passes back into the REST API (`GET /api/risks/root/{rootID}`, `GET /api/activities/{rootID}/full`, `GET /api/documents/getLineGuidanceForRoot/{rootID}`, ...) to retrieve the full detail. Queues are provisioned per client, and optionally per team, by Whitespace Support, which supplies the queue name, key and connection string. Delivery is at-least-once by default (lock, process, settle; unsettled messages are unlocked and returned to the head of the queue); at-most-once is available on request. Messages never expire and each queue holds more than a quarter of a million messages. Pull-based delivery supports up to 100 simultaneous connections, and Azure's push APIs are unlimited. Duplicate detection, peek, and a dead-letter drop for poison messages are all part of the Service Bus layer. NOT AN OFFICIAL WHITESPACE ARTIFACT. Channel addressing, the message schema and the complete activity-string enumeration below are transcribed from "Integrating with Whitespace via Queues" v3.1 (7 March 2025, platform 3.1) and "Queues and the Whitespace Platform" v1.2.2. Nothing here is invented; anything the guides do not state is left out.
Channels
Messages
Servers