Skip to content

Events

PREQSTATION writes mutation events to events_outbox. The web app reads those events through /api/events for audit and integration workflows.

Event Types

Common event types include:

Task events

EventMeaning
TASK_CREATEDA task was created
TASK_STATUS_CHANGEDWorkflow status changed
TASK_UPDATEDTask fields changed
TASK_DELETEDA task was deleted

Work log events

EventMeaning
WORKLOG_CREATEDA work log entry was created
WORKLOG_UPDATEDA work log entry was updated
WORKLOG_DELETEDA work log entry was deleted

Project events

EventMeaning
PROJECT_CREATEDA project was created
PROJECT_DELETEDA project was deleted

events_outbox Schema

The current table shape is:

CREATE TABLE events_outbox (
id BIGSERIAL PRIMARY KEY,
owner_id UUID NOT NULL,
project_id UUID,
event_type TEXT NOT NULL,
entity_type TEXT NOT NULL,
entity_id TEXT NOT NULL,
payload JSONB,
created_at TIMESTAMP WITH TIME ZONE NOT NULL
);

Key points:

  • id is a monotonic cursor, not a UUID
  • entity_id is text because it may contain a task key such as PROJ-123
  • there is no processed_at column in the current schema

/api/events

GET /api/events is an internal session-auth endpoint.

Query parameters:

  • after (optional): last event cursor already processed
  • projectId (optional): filter to one project UUID
  • limit (optional): defaults to 50, max 100

Response shape:

{
"events": [
{
"id": "42",
"eventType": "TASK_STATUS_CHANGED",
"entityType": "task",
"entityId": "PROJ-123",
"payload": {
"from": "todo",
"to": "ready"
},
"createdAt": "2026-03-12T14:35:00.000Z"
}
],
"nextCursor": "42"
}

Polling Pattern

  1. Call /api/events
  2. Process returned events in order
  3. Save nextCursor
  4. Poll again with ?after=<nextCursor>

Work Logs and Events

Task lifecycle mutations often create work logs behind the scenes. For example, preq_complete_task() writes a work log entry and also emits WORKLOG_CREATED plus task events.

Typical Uses

  • audit trails
  • notifications
  • lightweight internal integrations
  • activity timelines