Skip to main content

Streaming Integration (SSE)

Set responseMode: "stream" to receive progressive compliance results as each agent finishes. The connection stays open until the run completes; events arrive as soon as each phase produces output. Useful when you want to show live progress in a UI rather than waiting 60–240 seconds for a single sync response.

Endpoint

The response is Content-Type: text/event-stream. Time-to-first-event is typically under 1 second.

Event sequence

A successful run produces this sequence (events are SSE format: event: <type>\ndata: <json>\n\n):
The terminal event is always either complete (success) or error (failure). After a terminal event the server closes the connection.

Event types

agentId is one of: ai-laws, advertising-law, rights-clearance, rights-clearance-image, metadata-labeling, platform-policy.

Client implementation

EventSource (browser)

curl

For quick testing:
The -N flag disables curl’s output buffering so you see events arrive progressively.

Concurrent stream limit

A maximum of 5 concurrent streams per tenant is enforced. Requests over the cap return 429 with a message advising retry. The cap exists to prevent runaway clients from holding open many connections at once. If you legitimately need higher concurrency, contact support.

When to use streaming vs. async

Streaming holds a connection open for the entire run (typically 60–240 seconds depending on mode and scope). Choose:
  • Streaming when you want to render live progress in a UI and the client can keep a connection open.
  • Async + webhook (guide) when the client can’t or shouldn’t hold a connection open — server-to-server pipelines, mobile apps, or batch workflows.
  • Sync (the default) when the run is short enough that progress events aren’t worth the complexity.

Error handling

A pipeline failure delivers a single error event then closes:
Network disconnects mid-run: the orchestration continues server-side until completion. To recover the result, store the request with a sync re-issue or — preferred — use responseMode: "async" from the start so the result lands in your webhook and persists in the polling endpoint.

Limitations

  • No resume from a specific event. There is no resumeFrom=advertising-law query parameter. If the connection drops, re-issue the request (idempotency keys deduplicate).
  • No partial fallback. If the orchestrator fails mid-run, the server emits one error event with the failure reason — partial check results are not returned.
  • Multipart requests stay sync. The multipart/form-data upload path does not support responseMode: "stream". Pass image URLs in the JSON body if you need streaming with image inputs.