Zapier Log Streams send selected Zapier activity as JSON webhook notifications to an HTTPS endpoint you choose. That endpoint can be a customer-managed collector that validates, routes, and indexes records in a SIEM or log store. The documented delivery path is not a verified native Splunk or Datadog connector.
This guide covers the practical setup and ingestion decisions behind that architecture: which events to select, how Audit Log records differ from Zap execution events, how to verify signed requests, and how to preserve event-level identity without creating duplicate records.
Log Streams are available on Zapier Enterprise. Account owners and super admins can create or manage them. The Audit Log is an interface for reviewing account activity, while a Log Stream delivers selected events to an external destination.
What Zapier Log Streams send and where the data goes
The documented architecture is Zapier Log Stream → customer-selected HTTPS POST endpoint → customer-managed collector or SIEM. The endpoint must accept POST requests over HTTPS. A collector can verify the webhook, preserve the original payload, and forward or index it in a SIEM such as Splunk or Datadog if the organization’s receiving system supports that route.
Choose the receiving system before creating the stream. Confirm that it accepts JSON, can inspect the required headers, and can verify HMAC-SHA256 signatures if you configure a secret. If the SIEM cannot perform those tasks directly, place an HTTPS collector in front of it. Describe the result as webhook ingestion to a collector, not as a finished native SIEM integration.
The Log Stream and Audit Log serve different purposes. The Audit Log is a review interface for account activity. The stream is a delivery mechanism for selected Audit Log and Zap execution events. Execution events describe individual Zap run outcomes and do not appear in the Audit Log.
Treat the HTTPS endpoint as an ingestion boundary: verify the request first, preserve the source record, then let the receiving system decide how to route or enrich it.
Choose events by investigation or monitoring job
Zapier documents two event families with different grains and payloads. Audit Log events describe account, configuration, and asset activity. Zap execution events describe individual runs with outcomes such as success, error, or halted.
| Event family | Record grain and useful fields | Monitoring question |
|---|---|---|
| Audit Log | One account activity event, with fields such as event_id, actor, location, timestamp, action, affected object, and context. |
Who changed or accessed an account asset, and what was affected? |
| Zap execution | One Zap run, with fields such as asset_id, run_id, status, start time, error message, and owner information. |
Which Zap runs are failing, stopping, or completing? |
Current documented Audit Log categories include app connections, variables, MCP servers, API credentials, folders, and Zaps. The selection screen supports choosing a category or expanding it to select individual events. Event availability can change, so use the current Audit Log event reference and the stream-selection screen rather than treating the announcement’s “45+ events” statement as a complete inventory.
For an access or configuration investigation, select relevant account, permission, connection, or asset events. For run-health monitoring, select the execution outcomes needed by the operations team. Use the event key as a routing discriminator and confirm that the required key is available before building an alert around it. Avoid broad collection without a named owner, destination, and retention purpose.
Set up the stream and its receiving endpoint
In an eligible Enterprise account, an owner or super admin goes to Admin Center > Insights > Log streams. Create a named stream, provide an HTTPS destination that accepts POST requests, optionally configure or generate a secret, and select event categories or individual events. Create the stream to begin delivery for the selected subscriptions. It cannot retrieve activity that occurred before capture began.
Event subscriptions are configured per stream. If additional event types are needed, review and edit the stream rather than assuming future categories will be included automatically. Zapier’s documentation also provides a test webhook management function, but that does not replace receiver-side validation and monitoring.
Zapier offers a template that opens a draft Zap with a Webhooks by Zapier trigger named “Receive Log Stream events.” The builder must configure subsequent actions and turn on the Zap. It is not a completed Slack or Jira workflow, and the documentation does not establish built-in filtering, deduplication, retries, or human approval for the resulting Zap.
Validate signatures and keep event schemas distinct
When a secret is configured, Zapier signs webhook requests using HMAC-SHA256 and sends the X-Zapier-Signature and X-Zapier-Timestamp headers. The signed message is the timestamp, a period, and the raw request body. Verify the signature before parsing JSON, using a constant-time comparison. Parsing and re-serializing the body first can invalidate verification.
Zapier documents the timestamp header but does not prescribe an acceptance window. A receiver may add a timestamp-age check as a replay-resistance safeguard, provided that the rule is clearly treated as receiver-side policy rather than a Zapier requirement.
These abbreviated fragments illustrate the two documented shapes. They are illustrative, not complete payload schemas.
{
"event_id": "illustrative-event-id",
"actor": {},
"where": {},
"when": "illustrative-timestamp",
"what": {},
"affected_object": {},
"context": {}
}{
"asset_type": "zap",
"asset_id": "illustrative-zap-id",
"run_id": "illustrative-run-id",
"status": "error",
"started_at": "illustrative-timestamp",
"error_message": "illustrative error text"
}Preserve the original payload alongside normalized fields. An Audit Log record may not contain an IP address, so do not make that field mandatory. After signature verification, identify the event family, validate its required fields, and send invalid signatures or malformed records to a quarantine path owned by the ingestion team.
Verify the request over untouched bytes, identify the event family, validate that family’s fields, preserve the raw payload, and only then route it to an Audit Log or execution-event index. A shared webhook endpoint does not justify a shared rigid schema.
Route records with event-level identity
A practical receiver-side observation record can include source account context, event family, event key, event_id for Audit Log events or run_id for execution events, original event timestamp, actor or owner, affected object or asset, raw payload, receipt time, and signature-verification result. This is an implementation design, not a Zapier-published storage schema.
Use event_id as the Audit Log event-level identifier and run_id as the execution-event identifier. asset_id identifies the Zap, not an individual run. Do not deduplicate Audit Log activity by object and date, or execution records by Zap ID and status. Zapier documents the identifiers but does not define their uniqueness scope across accounts, streams, or destinations.
Namespace the deduplication key with a verified source or account identifier supplied by the ingestion layer. If multiple streams can feed the same store, preserve the collector-assigned stream or source context rather than inventing a Zapier payload field. Enforce uniqueness with a database constraint and transactional insert-on-conflict or upsert. A lookup followed by an insert is not safe when workers process concurrent requests.
Use deterministic rules for event-key routing, known actors, asset scope, and high-risk changes. AI is not needed to verify signatures, parse fields, check allowed status values, deduplicate records, or match a known event key. If useful, apply AI only after filtering to summarize a verified sequence for an analyst. Require the output to reference source event IDs and leave consequential decisions to a named human owner.
| Use case | Trigger and AI boundary | Validation and destination | Human fallback |
|---|---|---|---|
| Security change alert | A selected Audit Log event key and affected object match a defined high-risk rule. No AI is required for the match. | Verify signature, account scope, and event ID. Save the original event with a security case or notification. | Security owner reviews ambiguous matches and any proposed remediation. |
| Execution error monitoring | An execution event reports an error or halted run. Route by asset_id and status; AI may summarize supplied error context. |
Validate status and run_id. Store one record per run in an operations index or queue. |
Zap operations owner investigates repeated errors or unassociated assets. |
| Analyst-assist summary | Filter and group verified events first. AI summarizes the selected sequence, but does not authorize action. | Require structured output tied to source event IDs. Store it as derived material, not the source record. | Analyst checks the underlying events before taking action. |
Zapier documentation describes Slack notifications and Jira ticket creation as possible patterns. A resulting alert or ticket should retain the source event identifier, timestamp, event key, actor, affected object, and source account so an operator can return to the original record.
Check capture, retention, and operational limits
Log Streams capture events from stream creation onward and cannot retrieve earlier activity. When an event type is added to an existing stream, capture begins for matching events after that subscription is configured. The Audit Log provides up to six months of retention on Team and up to twelve months on Enterprise, while a Log Stream can preserve received data in the organization’s own system from the point capture begins.
The reviewed documentation does not establish webhook retry, replay, ordering, delivery-guarantee, timeout, or customer-visible dead-letter behavior. Plan receiver-side monitoring, invalid-signature quarantine, duplicate handling, access control, retention, and recovery independently. Do not promise recovery of events missed before setup or while the endpoint is unavailable.
Before relying on a stream for investigations, record its enablement date, verify the selected event key and receiving path, and assign an owner who can find signature failures, schema exceptions, and ingestion outages.
- The intended event key is selected and an expected event reaches the HTTPS collector.
- Signature verification passes against the raw request body when a secret is configured.
- The original event timestamp, event key, and event-level identifier are preserved.
- A database uniqueness constraint blocks duplicate writes for the receiver’s declared row grain.
- A named owner can locate and investigate quarantined, malformed, or unavailable records.
Common questions
Does Log Streams deliver directly to Splunk or Datadog? The verified delivery contract is a customer-selected HTTPS POST endpoint. A customer-owned collector may forward or index the data in a SIEM, but a native direct connector was not verified.
Can a new stream retrieve earlier Audit Log events? No. Log Streams capture events from stream creation onward and do not provide historical backfill.
Does Zapier retry or replay failed webhook deliveries? The reviewed documentation does not specify retry or replay behavior. Monitor the receiver and define an independent exception and recovery process rather than assuming missed events will be resent.
For teams planning broader Zapier operations around this ingestion architecture, see Zapier automation consulting.
