Stream console updates with SSE
Use Last-Event-ID to resume brand activity without replacing durable webhook processing.
Connect to GET /v1/events/stream with brand authorization, process event IDs and types, and send Last-Event-ID when reconnecting. Use SSE for responsive consoles and webhooks for durable server-to-server workflows.
What this means in practice
Connect to GET /v1/events/stream with brand authorization, process event IDs and types, and send Last-Event-ID when reconnecting. Use SSE for responsive consoles and webhooks for durable server-to-server workflows.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Open one bounded stream per active brand view rather than per widget.
Store the last processed event ID only after applying the update.
Reconnect with backoff and Last-Event-ID after network loss.
Refresh the resource through REST when an event indicates your local representation is stale.
Close inactive browser streams and handle authentication expiry visibly.
Example request
This example uses a server-side API key and an explicit brand selection. Replace placeholder values and keep credentials out of browser bundles, client logs, and source control.
curl --request GET \
--url 'https://postapi.app9.co/v1/events/stream' \
--header 'Authorization: Bearer APP9_POST_API_KEY' \
--header 'X-App9-Post-Brand: BRAND_ID'Operational details
SSE transports brand events over a long-lived HTTP response.
A browser can miss events outside the retention window and should then reload current state.
Event data is sanitized and brand-scoped.
Common mistakes to avoid
- Do not treat SSE as a durable queue for backend business processes.
- Do not open duplicate streams on every React rerender.
- Do not assume global event ordering across unrelated resources.