/v1/events/batch endpoint lets you record up to 100 audit events in a single API call. Batching is the recommended pattern for high-throughput services — it reduces round-trip overhead, and the entire batch counts as just one request against your rate limit. Each event in the array follows the same structure as a single event: an action is required, while actor_id, resource, and metadata are optional. If you only need to record one event at a time, see the single event endpoint instead.
Request
POST https://api.auditrails.io/v1/events/batch
Headers
string
required
Your AuditRails API key, prefixed with
Bearer. Use a live key (at_live_xxx) for production traffic and a test key (at_test_xxx) for development.Example: Bearer at_live_xxxstring
required
Must be
application/json.string
An optional client-generated string (e.g. a UUID) that makes the entire batch safe to retry. If you resend the same key with an identical request body, AuditRails replays the original 202 response and sets the
Idempotency-Replayed: true response header — no duplicate events are written.Sending the same key with a different body returns a 409 conflict error. Keys are retained for 24 hours.Body
array
required
An array of event objects to log. Must contain between 1 and 100 events. The batch is processed atomically — if any single event fails validation, the entire batch is rejected and nothing is written. Correct all validation errors and resubmit the full batch.Each event object supports the following fields:
Example request
Atomic writes: The batch endpoint writes all events or none. If any event in the array fails validation — for example, a missing
action field — the entire batch is rejected with a 422 error that identifies the offending index (e.g. event[2]: action field required). Correct every flagged event and resubmit the complete array.Rate limiting: Regardless of how many events are in the array, the batch endpoint counts as a single request against your rate limit. Batching is the most efficient way to ingest high volumes of events without hitting rate limits.
Response
A202 Accepted response means all events in the batch have been durably written and sealed.
202 Accepted
array of strings
An ordered array of unique, immutable identifiers for each accepted audit log entry. The IDs are returned in the same order as the events in your request array, so
log_ids[0] corresponds to events[0], log_ids[1] to events[1], and so on. Each ID is a ULID — lexicographically sortable and time-prefixed.string
A unique identifier for the API request itself. Include this value in any support tickets or bug reports related to this call.