GET /v1/reports/{id} for it.
GET /v1/streaming/events describes the contract in machine-readable form. This page covers the consumer side: what the manifest tells you, what arrives on the wire, and what each event carries.
The manifest operation
Streaming events returns the static event catalog. It requires authentication like every other operation. It answers
Cache-Control: no-store, and it responds whether or not this deployment publishes events. Read it at startup to check that your consumer and Reporter agree on the contract.
The response exposes the application identity and catalog:
Broker routing
The manifest does not disclose a topic or broker topology. Bind your queue to the exchange named by
RABBITMQ_REPORT_EVENTS_EXCHANGE. Each message uses the event definition key verbatim as its AMQP routing key: report.finished, deadline.delivery_reverted, underscores included.
When STREAMING_KAFKA_BROKERS is set, report.finished and report.partial also publish to the Kafka topic lerian.streaming.reporter, in addition to RabbitMQ.
The event catalog
Seventeen event definitions exist across the two run modes.
This channel is publish-only. Reporter emits these events and consumes none of them.
Delivery
Every manifest event has class
fact. The delivery profile in the table above selects its delivery policy.
An event with the
Critical delivery profile therefore never publishes straight to the broker. Reporter writes it to the durable Mongo streaming outbox after the business-state commit, and a dispatcher replays it after a broker outage.
The state write and outbox insert are separate operations, not one atomic application transaction. That gap is a failure window: a crash or a failed outbox insert after the state commit loses the event. No reconciliation recovers it. The loss leaves only an error log and a metric. Once the row is in the outbox, the dispatcher retries until delivery.
The policy requests dead-letter handling for routable failures, but the current RabbitMQ routes do not provide an explicit DLQ destination. Such a failure is surfaced and logged, with no forensic dead-letter copy.
Emission happens after the commit and never fails the work. A publication problem does not turn a stored report into an errored one.
The CloudEvents envelope
Messages travel in CloudEvents binary mode, version 1.0. Context attributes ride as message headers.
Reporter marks messages persistent and always stamps a tenant value.
What a payload carries
Payload keys are
snake_case, unlike the camelCase REST surface. A report.finished body:
artifact_object_key is the exact object key reported by storage after the write, not a path that consumers should reconstruct. Use the value verbatim.
If you validate its tenant segment, compare it with the tenant bound to your authenticated subscription, not with another field from the same message. An empty key on report.finished or report.partial is a contract violation. Download a report remains the supported way to fetch a report in the Finished state.
report.partial adds section_failures and failed_section_count alongside the same artifact fields. A resolvable key does not mean that the report is complete. Deliver a template report only from report.finished, and a regulatory filing only from regulatory.filing_approved. Strictly decode the status field instead of using key presence as the discriminator. regulatory.filing_approved names the approved file in artifact_object_key and carries artifact_sha256, artifact_size_bytes, delivery_attempt, and approved_by.
document_type carries the category of the template. report.errored replaces the artifact fields with error_code and error_summary, and adds document_id and document_version, which name the regulatory document when a subscription generated the report. Its lack of an artifact field does not prove that no object was written: storage can succeed before terminal status persistence fails, leaving an object that no event names. Both error fields come from a fixed vocabulary: report_generation_failed, report_generation_timeout, report_generation_canceled, or report_worker_lost. Each code has a fixed summary. Raw error text never travels on the wire, so a payload cannot leak a query, a connection string, or tenant data. Branch on error_code.
Enabling event publication
Event publication is a deployment choice, set with
STREAMING_ENABLED. Turn it on and Reporter requires three more settings at startup:
When publication is off,
STREAMING_CLOUDEVENTS_SOURCE may be unset. If it is set, it must still be exactly reporter. Reporter rejects another non-empty value at startup even while publication is off. When publication is on, Reporter also refuses to start if any of the three settings is blank, so a misconfigured deployment fails at startup instead of dropping events quietly.
Next steps
Reporter REST API
The 56 operations, authentication, pagination, and errors.
API Reference
The streaming manifest operation, with its full response shape.
Environment variables
Every setting behind the streaming, exchange, and run-mode surfaces.
What is Reporter?
Templates, reports, deadlines, and where they fit.