Sending audit logs to customers

In today’s heterogeneous workplace, where employees may be intermingling with LLM-powered AI agents, outside contractors, and vendors in the same set of tools, reliable audit logs are an essential part of doing business. SIEM products like Panther and Splunk can provide a single-pane-of-glass interface on top of these audit logs, and Svix is the essential glue to get data from your system directly to your customers’ SOCs, so that security engineers can easily integrate your logs with the hundreds or thousands of other systems that they might be monitoring. This guide will walk you through exporting audit logs into your customers’ SIEMs.

What Goes Into a Good Audit Log?

Before you can send audit logs to your customers, you first need to decide what to put into the log records themselves. Audit logs should capture all security-sensitive actions in your system; at a minimum, you should make sure to emit logs for all user and group activities, and for other key activities in your system that could be used by an attacker. Some examples we’ve seen from our customers:

• Login attempts
• User creations and deletions
• Group membership changes
• Data imports and exports
• Security credential creation (e.g., password or passkey changes, API token creations)

Structuring Your Events

Security Operations Centers work best with wide events and with as much context as possible; JOINs are often expensive or impossible, and alerting rules will typically work on a small window of logs. When emitting audit logs, it’s best to make sure that each individual event contains as much information as possible. While every SIEM vendor has slightly different schemata, we recommend using a common base like the Elastic Common Schema  for your audit logs. For example, for a user login, you might have an event like the following:

{
  "@timestamp": "2026-09-07T22:56:32.123Z",
  "event": {
    "action": "user.login-attempt",
    "kind": "event",
    "outcome": "success"
  },
  "ecs": {
    "version": "8.17"
  },
  "user": {
    "id": "123456",
    "email": "foobar@example.com"
  },
  "com.your.product.customfields": {
    "session_expires_at": "2026-09-08T22:56:32+00:00"
  }
}

Note that the @timestamp, event, and ecs keys are all mandatory; the user key contains fields from the ECS user vocabulary , and custom fields can be inserted under a custom top-level key.

It can often be valuable to make each event.action in your logs correspond to a single event type in Svix so that your customers can filter their destinations and only receive the events they want.

Sending Audit Logs

Create one application per customer with the create application API . Setting the application’s uid to your internal customer id lets you send messages without storing Svix ids.

Send the audit logs from your application code with the create message API . You don’t need to worry about batching them for easy ingestion. Svix takes care of batching, retries, and delivery to that customer’s destinations. Messages are saved even before a destination exists, so you can start emitting logs as soon as the customer does.

Consuming Audit Logs

Once those applications are receiving audit logs, your customers consume them by adding destinations, either in the App Portal or through the API.

For many SIEMs, the fastest way to get started is an object storage destination such as Amazon S3 or Google Cloud Storage. That writes events as newline-delimited JSON  to a bucket, and the customer points their SIEM at the bucket. They can then set their own retention and deletion-lock rules on that bucket. For example, in Panther, users could configure an “S3 Source”.

Customers using the Elastic Security project can use an ElasticSearch destination to send the logs to Elastic.

Object storage and ElasticSearch are advanced destinations, so they need to be enabled for the environment before customers can create them.

Customers who are using a SIEM that doesn’t natively understand ECS logs can reformat them with a transformation on the destination. For example, a customer using the Google Security Operations platform might want their data formatted as UDM instead. They could do that with the following transformation, combined with the Google SecOps Webhook feed .

function transformEvent(event) {
  return {
    metadata: {
      event_timestamp: event["@timestamp"],
      event_type: "USER_LOGIN",
    },
    target: {
      user: {
        userid: event.user.id,
      },
    },
  };
}
 
function handler(webhook) {
  webhook.payload = transformEvent(webhook.payload);
  return webhook;
}

Wrapping Up

At this point, your customers should be well-equipped to monitor activity in your system. Please reach out if you have any other questions; the team will be happy to help!