Overview
Events are the fundamental unit of Immutable. Each event represents a single action taken by an actor on a resource. Events are append-only — once recorded, they cannot be modified or deleted through the API. The API provides noPUT, PATCH, or DELETE endpoints for events. Each event is cryptographically linked to the previous event in a hash chain, making any tampering at the database level detectable.
Event Anatomy
When you retrieve an event from the API, it contains the following fields:UUID v4 identifier, pre-generated at ingestion time.
The entity that performed the action.
actor.id(string) — Identifier of the actor. Example:user_2hG9kLm.actor.name(string | null) — Human-readable name. Example:Sarah Chen.actor.type(string | null) — Type of actor. Example:user,system,api_client.
The action performed, typically in
resource.verb format. Example: document.created.Optional category for grouping actions. Example:
documents, billing.The primary resource affected.
resource.type(string | null) — Resource type. Example:document,invoice.resource.id(string | null) — Resource identifier. Example:doc_8nXpQr3.resource.name(string | null) — Human-readable name. Example:Q4 Financial Report.
Array of additional resources involved. Each target has
type, id, name, and optional metadata. See Targets.Arbitrary JSON object for additional context. Example:
{"folder": "reports", "pages": 12}.Your customer’s tenant identifier for multi-tenant isolation. Example:
org_7rT2xBc.Session identifier for grouping related events. See Session Tracking.
Two-letter ISO country code derived from the client IP. Example:
US.City name derived from the client IP. Example:
San Francisco.Unique key for deduplication. Duplicate events with the same key return the original event ID with status
duplicate.Version number for the event schema. Useful for tracking event format changes over time.
Hash chain proof.
integrity.event_hash(string | null) — SHA-256 hash of this event.integrity.previous_event_hash(string | null) — Hash of the preceding event in the workspace chain.
ISO 8601 timestamp of when the event occurred (client time). Defaults to server time if omitted during ingestion.
ISO 8601 timestamp with microsecond precision of when the event was recorded server-side.
Example Event
Async Processing
Event ingestion is asynchronous. When youPOST /api/v1/events, the API returns 202 Accepted immediately with a pre-generated UUID. The event is processed in a background queue (hash computation, geo enrichment, alert evaluation, log stream fanout).
Idempotency
Include anidempotency_key to prevent duplicate events from retries or network issues. If Immutable receives a second event with the same idempotency key within the same workspace, it returns the original event ID with status duplicate:
Geo Enrichment
Immutable automatically enriches events with geographic data derived from the client IP address using MaxMind GeoLite2:ip_country— Two-letter ISO country code (e.g.US,GB,DE)ip_city— City name (e.g.San Francisco,London)
null for both fields. See Geolocation for details.
Microsecond Timestamps
All timestamps use microsecond precision (TIMESTAMP(6)) and the format Y-m-d H:i:s.u. This enables precise ordering even during high-throughput ingestion and ensures stable cursor pagination.