Get Foundry events

Returns a paginated list of Foundry events in reverse chronological order, providing an audit trail of Foundation build approvals, auto-update configuration changes, and related actions.

Use this endpoint to programmatically access the Foundation Event Feed — the same activity log visible in the Esper Software Updates > Foundation Event Feed tab — for monitoring, compliance reporting, or automated alerting on Foundation update activity.

About Get Foundry Events

The Foundation Event Feed records significant actions taken within the Foundry system, including build approvals and unapprovals, auto-update configuration changes, and other state transitions. Each event captures the actor (user or system), the affected resource, the event type and message, and any remarks provided at the time of the action. This log is essential for change management auditing — especially in regulated environments where OS update approvals require traceability. Events are returned in reverse chronological order (most recent first).

Key Fields / Query Parameters

limit — Number of events to return per page

offset — Starting index for pagination

actor — Object identifying the user or system that triggered the event (includes id and name)

event_type — Classification of the event (e.g., build approval, auto-update change)

event_message — Human-readable description of what occurred

resource — Object identifying the affected resource (id and type, e.g., a specific build or device model)

meta.user_remarks — Any comment provided by the actor at the time of the action (e.g., approval rationale from PUT /v1/foundry/builds/{build_id}/)

meta.change_type — The type of change recorded

created_timestamp — Unix timestamp of when the event occurred

Common Use Cases

Auditing the history of build approvals and auto-update configuration changes for compliance or change management records

Monitoring for unexpected approval or configuration changes as part of a security or operations workflow

Correlating Foundation update events with device behavior observed in device telemetry or command history

Best Practices

Paginate with limit and offset to retrieve a bounded window of recent events rather than loading the full history in a single call

Persist events to an external log store if long-term retention is required — Foundry does not guarantee indefinite event history

When using PUT /v1/foundry/builds/{build_id}/ or PUT /v1/foundry/device-models/{device_model_id}/, always supply user_remarks — these notes appear in this event feed and significantly improve audit trail quality

Workflow

Call GET /v1/foundry/events/ to retrieve recent Foundation activity, paginating as needed

Filter results client-side by event_type or resource.id to isolate events related to a specific build or device model

Cross-reference meta.user_remarks and actor fields with internal change management records for compliance verification