GoodTime SIEM Agent

The GoodTime SIEM Agent provides organizations with a centralized, tamper-resistant audit trail of security activity across the GoodTime platform. It automatically records security-relevant events; such as user logins, permission changes, API key updates, and administrative actions, and stores them for a configurable retention period (30 days by default). In addition to providing administrators with a searchable history of these events for auditing and compliance purposes, the SIEM Agent can forward events in real time to external security and monitoring platforms, including popular SIEM solutions such as Splunk, Microsoft Sentinel, Elastic, Google Chronicle, and AWS Security Lake. This enables security teams to incorporate GoodTime activity into their existing monitoring, alerting, and incident response workflows while maintaining a complete and immutable record of security events.

What is the GoodTime SIEM agent?

The SIEM Agent is GoodTime's audit and event-forwarding system. It has three jobs:

1. Record security events. Every time something security-relevant happens in the platform — a user logs in, a role is granted — the Security Service receives that event and stores it. These records are immutable: once written, they cannot be edited or deleted before their retention window expires.

2. Expose event history. The stored events can be browsed and searched through a read API, allowing the frontend to show administrators a full audit trail filtered by user, event type, or time range, with cursor-based pagination for large result sets.

3. Forward events to external systems. Customers can configure rules that send copies of these events, in real time, to a URL of their choice (a SIEM tool, a Slack webhook, a custom endpoint, etc.). This is done through Webhook Rules.

Each event captures:

• What happened — the event type (e.g. user.login.failed)

• When it happened

• Who did it — the user or system that triggered the action

• Which organization it belongs to

• Details — a structured payload with context specific to that event type

How it all fits together

Event Bridge
  │
  ▼
Security Service
  │
  │
  ├─ siem_enabled = false? → drop event
  ├─ event type not in allowed_event_types? → drop event
  │
  ├─ Store event (immutable, retained for data_retention_days)
  │
  └─ Match against Webhook Rules
       │
       ├─ Rule A (format: ecs, url: elastic-endpoint) → deliver
       └─ Rule B (format: ocsf, url: aws-security-lake) → deliver
                    │
                    └─ on failure: retry with backoff (up to maxRetries)

Webhook Configuration

A Webhook Rule tells the Security Service: "when an event of type X arrives for our

organization, send it to this URL.”

The system tracks a health score per rule based on the last 10 delivery attempts. A rule with fewer than 70% successful deliveries is considered unhealthy. The frontend can surface this to help administrators identify failing destinations.

Each rule has the following options:

Configuration Fields

Enabled: Rules can be toggled without deleting them. Disabled rules receive no events.

Event Filter:

• Wildcard (*) — every event, regardless of type, triggers this rule - Default

• Single type — e.g. user.login.failed — only that specific event

• List of types — e.g. ["user.login.failed", "user.account.locked"] — any of those types

Destination URL: The HTTPS endpoint where events are delivered. Must be a valid URL.

Payload format: The Security Service can transform events into several industry-standard formats before sending them, so they are ready for import into popular SIEM and log management tools without additional processing.

Max retries: How many times the system will retry a failed delivery before marking it as permanently failed. Range: 0–10. Default: 3.

Attempt → Delay before retry

• 1st retry → 15 seconds

• 2nd retry → 30 seconds

• 3rd retry → 1 min 30 sec

• 4th retry → 4 minutes

• 5th retry → 7 min 30 sec

• 6th–10th → Up to 4 hours

Delivery Statuses

Each delivery attempt for a rule shows one of these statuses:

Failed deliveries can also be retried manually from the frontend.

Public API

The Security Service exposes a read API so the frontend (or any authorized client) can browse and search the organization's stored event history.

Access requirement: requests must carry a token that includes the siem scope. A valid session alone is not enough — tokens without this scope receive a 403.

List events

Returns a page of events for the authenticated organization, ordered from newest to oldest.

Filters — all optional, can be combined:

Pagination — the response includes links.next and links.prev cursor URLs ready to

use:

after and before are mutually exclusive — only one can be used per request.

Payload format — the format parameter controls the shape of each event's payload field, using the same six formats supported by webhook rules (raw, cim, ocsf, ecs, asim,

chronicle_udm). Default is raw.

Get a single event

Returns the full details of one event by its ID. Accepts the same format parameter as the list endpoint.

Global Settings for Organization

These settings apply to the entire organization and control whether and how events are processed. They can be read, changed, or removed through the Settings API.

SIEM enabled

A master on/off switch. When disabled, no events for that organization are processed or stored

— they are silently dropped as they arrive.

• Default: enabled (events are recorded)

• Options: true (record events) / false (drop all events)

Use case: an organization that wants to temporarily pause event collection, or that prefers to opt in rather than opt out.

Allowed event types

A filter that limits which event types are recorded for the organization. Events not on the list are dropped before storage — they will also never be forwarded to webhooks.

• Default: all event types are accepted (no filtering)

• Format: comma-separated list of event type strings, e.g.

  user.login.failed,user.account.locked

• Empty value: same as default — accepts all types

Use case: an organization that only cares about authentication failures and account lockouts, and does not want noise from administrative events.

Data retention

How many days of events, webhook deliveries, and delivery attempt logs are kept before being automatically purged. Once data is purged it cannot be recovered.

• Default: 30 days (system-wide default, not stored per org)

• Format: positive whole number of days, e.g. 90

• Effect of deleting the setting: reverts to the 30-day system default

Supported Event types

Events are grouped into four categories. The exact string values listed below are what the system uses internally. They matter when configuring webhook rules or event-type filters.

Authentication

Covers logins, logouts, and multi-factor authentication.

Access Control

Covers permissions, roles, and who can see or do what.

API Keys & Tokens

Covers programmatic access credentials.

Administrative

Covers organization-level and settings changes.

References

• Public API Documentation - StopLight

• Splunk CIM Model Spec

• Elastic ECS v8.11.0 Model Spec

• Microsoft ASIM Model Spec

• OCSF v1.1.0 Model Spec

• Google Chronicle UDM Model Spec