Skip to main content
Use GET /search/{id}/stream to follow search execution in real time.

Concrete stream example

Run this against an existing SEARCH_ID:
Typical successful session:
Typical BYOK session (providers + completion):
Typical sharding/capacity session:
Typical failed session:

Event types

connected

Sent immediately after the SSE connection is established.

module.result

Sent when one module emits a result card.
Fields:
  • search_id: search UUID
  • module.id: module identifier when available
  • module.name: module display name
  • card: raw card payload
  • timestamp: event time

search.progress

Sent during orchestration and shard execution.
Fields:
  • status: queued or running
  • message: human-readable progress (for example capacity waits or shard progress)
  • result_cards_count: optional running count

byok.result

Sent when a BYOK provider emits one raw card event.
Fields:
  • provider: osint_industries or sherlockeye
  • card: provider-emitted card payload

byok.finished

Sent once per provider when provider execution completes.
Possible status values:
  • success
  • no_results
  • failed

search.finished

Sent when the search reaches a terminal state.
Possible values for status:
  • completed
  • failed
Optional fields:
  • totals.module_results
  • execution_time_ms
  • error

leak.status

Sent for each leak source as it executes.

leaks.finished

Sent when all leak providers have finished or been skipped.

registered_accounts

Sent during registered-account checks.

breached_accounts

Sent when breached-account aggregation is ready.

Sharding model

For module execution, the orchestrator can split selected modules into shards and run them across multiple runners.
  • Max shard count is currently 3
  • Shards are assigned from runner capacity snapshots
  • If all runners are saturated, periodic search.progress events report waiting status
  • When capacity returns, execution resumes and progress messages include shard ratios (for example shard 2/3 progress 9/12)
Sharding details are implementation-level and may evolve, but these stream signals are stable integration points.

Resume and reconnection

Streams support resuming from an index:
  • Query params: start_index, cursor, or from
  • Header: Last-Event-ID
When available, each streamed event includes an SSE id: field. Store the last received id and reconnect from it after disconnects.

Notes

  • Keep the connection open until search.finished
  • The stream is additive: fetch GET /search/{id}/results for the normalized final payload
  • Leak results are retrieved separately through GET /search/{id}/results/leaks