This is a paid feature. See plans and pricing, or talk to sales about an enterprise plan.
Overview
Event Streaming sends every platform audit event to a destination of your choice, as it happens. Each destination has a format:- OpenTelemetry (OTLP). Each event is sent as an OpenTelemetry log record over OTLP/HTTP. This works with Datadog, PostHog, Grafana Loki, Grafana Cloud, New Relic, Honeycomb, Dynatrace, Elastic, SigNoz, Axiom, Better Stack, and any other backend that accepts OTLP logs. No collector or agent is needed in between.
- Raw JSON. The audit event is posted as-is to any webhook URL. Point it at a flow inside Activepieces and route each event to Slack, Gmail, Microsoft Teams, custom HTTP, and so on.
Quick start
Creating a destination is a three-step page: Destination, Events, and Connection.- Open Platform Admin → Security → Audit Logs → Event Streaming and click New Destination.
- Destination — pick Send to an OpenTelemetry tool or Send to a webhook. This choice sets the format, and you cannot change it once the destination is created.
- Events — select the events to send.
- Connection — paste the endpoint URL and add any headers the endpoint needs, such as an API key. For an OpenTelemetry tool, also pick the encoding. For a webhook, you can click Generate handler flow instead of pasting a URL, and Activepieces builds a flow to handle the events (see below). Use Send test event to fire a sample of any selected event.
- Click Create destination.
Generate a handler flow
Pick Send to a webhook on the Destination step, then click Generate handler flow on the Connection step. It builds a webhook-triggered flow with one router branch per event you selected, plus a nested branch for failed runs when you pickflow.run.finished. It fills the endpoint URL in for you. A webhook destination sends Raw JSON, which is the shape the generated flow routes on.

Formats
OpenTelemetry
Each event becomes one OTLP log record inside anExportLogsServiceRequest, posted to the endpoint URL. Pick an encoding:
- Protobuf (recommended) —
Content-Type: application/x-protobuf. This is the OTLP default and works with every backend listed below. Datadog, Dynatrace, and Elastic document only this encoding. - JSON —
Content-Type: application/json, the OTLP/JSON encoding. Pick it only when your receiver accepts JSON and not protobuf.
An attribute is left out when the event does not have that field. Lists inside
data are sent as one JSON string. Because every field is an attribute, you can filter and alert on it in your backend without a parser — for example data.flowRun.status:FAILED in Datadog.
Here is a flow.run.finished event in the OTLP/JSON encoding (the body string and some attributes are shortened):
OpenTelemetry endpoints
Where the table says Protobuf, pick Protobuf: the backend documents no JSON support. Splunk has no direct OTLP logs endpoint: run your own OpenTelemetry Collector with the Splunk HEC exporter and point the destination at the collector.
Raw JSON
The destination receives the audit event itself as the JSON body, withContent-Type: application/json. This is also what every destination created before formats existed keeps sending.
action— the event name (for exampleflow.run.finished).data— event-specific payload, including details like the flow id, run id, status, or affected user.id,created,updated— event identifiers and timestamps.platformId,projectId— context fields present on every event.userId,userEmail,ip— who did it and from where. These are filled in for events that come from a user request. The fourflow.run.*events are emitted by a worker rather than a request, so they carry none of them.
400.
Headers
Add any headers the endpoint requires — anAuthorization bearer token, a dd-api-key, an X-Scope-OrgID, and so on. The delivery sets Content-Type from the format, and it also owns Content-Length, Content-Encoding, Transfer-Encoding, Host, and Connection, so none of these can be added as a custom header. A header name may appear only once, whatever its letter case.
A handler flow on this instance receives the custom headers too, with lowercase names, exactly as an HTTP request to its webhook would. A Catch Webhook trigger that uses header or basic authentication can check them.
Header values are encrypted at rest and write-only. When you reopen a destination, saved keys are listed with an empty value and the placeholder Hidden — type to replace:
- Leave a value empty to keep the stored value.
- Type a new value to replace it.
- Delete the whole row to remove the header.
GET returns each header key with a null value, and sending null for a key on update keeps whatever is stored.
A stored value is bound to the URL it was saved against. If you change the URL, you must re-enter every header value in the same save — as soon as you change the URL, the form asks for a new value on each saved header you have not retyped, and the API answers 400 if an update changes the URL while keeping a stored value. This is what makes “write-only” true: without it, anyone who can edit a destination could point it at their own endpoint and have the next audit event deliver the secret for them.
Test, enable, and disable
Send test event on the Connection step builds a sample of the event you choose and delivers it in the selected format. It reports the HTTP status code, the round-trip time, and the body that was sent, so you can confirm the shape before you save. For the Protobuf encoding the body is shown in its OTLP/JSON form, since protobuf bytes are not readable. A test never reads a stored header value. It sends only the values typed into the form, so on a saved destination you must retype a secret to test with it. The button stays disabled, with a note, while any header value is blank or a header has an error. If the API refuses the test request itself, the card shows the reason. A result stays on screen only while the URL, headers, encoding, and event still match what was sent. Each destination has an Enabled switch on the listing page. A disabled destination keeps its configuration but receives nothing. The switch changes only that setting; if the change fails, it flips back and a message shows the reason.Available events
You can subscribe a destination to any audit event — flow lifecycle, run status, folder/connection changes, user activity, and platform admin actions. See the Audit Log Events catalog for the full list and per-event payload details.Requirements
- Enterprise Edition: Event Streaming requires a plan with Event Streaming enabled. Without it, no events are delivered.
- Platform admin: only platform admins can configure destinations.
- HTTPS endpoint: use HTTPS for any external endpoint. Audit events carry user emails and IP addresses, and Activepieces does not reject an
http://URL for you. - Publicly accessible: external endpoints must be reachable from your Activepieces server. Handler flows on this same instance are delivered internally, so they work even when the instance is not publicly reachable (for example, behind an internal load balancer).
Troubleshooting
- Events not received: check the destination is enabled. For external endpoints, verify they are reachable from your server and return 2xx status codes. For a handler flow on this instance, make sure the flow is published and enabled.
404from an OpenTelemetry backend: the URL is missing the logs path. Paste the full logs URL from the table above, not the base URL.415or a decode error from an OpenTelemetry backend: the backend does not accept the selected encoding. Switch the encoding to Protobuf.- Test fails: check that your URL is valid and uses HTTPS. The test reports the status code returned by the endpoint, which usually names the problem.
- Missing events: make sure the event type is selected in your destination configuration.
- A field is missing: the field is not on that event. The four
flow.run.*events carry nouserId,userEmail, orip, because a worker emits them rather than a user request.
See also
- Audit Logs — view every event recorded on your platform