The Event object describes events from your application that can be associated with Users , Companies, and Features. A new Event is created when it is submitted via the API.
Events are typically sent to Schematic to create or update Users or Companies (identify events), or to log usage events (track events) for usage analytics or metering.
Track events can have any number of subtypes denoting what event is being tracked (e.g. query_run, endpoint_added, etc.). Properties (e.g. num_users, num_endpoints, etc.) can be Events but we recommend they be submitted as traits on the Company and User objects.
Unique id generated by Schematic for the object.
The Schematic id associated with the feature tied to the event.
The Schematic id associated with the user tied to the event.
The Schematic id associated with the company tied to the event.
Datetime when event was sent to Schematic. Format is ISO 8601.
Effective timestamp of the event in Schematic. By default this is the server receipt time, but when the event is submitted with trusted_client_clock or backfill, it is the client-provided sent_at. Format is ISO 8601. See Backfills and usage corrections.
Datetime when event was loaded into the Schematic database. Format is ISO 8601.
Datetime when event was associated with objects in Schematic. Format is ISO 8601.
Datetime of last update to event data. Format is ISO 8601.
Unique identifier of Schematic environment the event is associated with.
There are two types of events - identify and track. identify events correspond to Company and User upserts. track events correspond to usage data.
track events can have any number of subtypes denoting what event is being tracked (e.g. query_run, endpoint_added, etc.). Subtypes are grouped together.
Current status of event in Schematic data pipeline (pending, success, failed, unknown).
Event payload sent to Schematic (either an identify or track payload).
Optional client-supplied key used to deduplicate events. If a second event is submitted with the same idempotency_key within 24 hours, scoped to the same environment and event type, it is dropped before processing.
Two optional boolean fields on the create-event payload let you submit events with client-provided timestamps. Both require a secret API key and a sent_at value. See Backfills and usage corrections for full semantics.
When true, the client-provided sent_at is used as the effective event timestamp instead of server receipt time. Billing side effects still fire. sent_at must be within 5 minutes in the future and 34 days in the past.
When true, the event is stored at its sent_at timestamp but all billing impact, webhooks, and last_seen_at bumps are skipped. Intended for analytics-only imports of historical usage. sent_at must be within 5 minutes in the future and 365 days in the past.